I’ve been doing FS work since before NT 3.1 shipped and in that entire
time I’ve always known that the kernel level maximum path length is 32k
characters. That’s the same as the limit imposed by the OS level API.
The decision to use a different value for applications running in one
(albeit important) subsystem of Windows is indeed a poor choice.
However, enforcing this different limitation in the *creation* but
accepting the OS maximum in the *use* would seem to be prudent. What I
object to is that the current paradigm seems to leave users in a
situation where applications die or cannot open files the user has
created on the underlying system.
Even the “don’t allow creation of such paths” isn’t very satisfactory
because it means users will be able to open such files, but when they
try to do anything with them (oh, like save them in their editor) their
operation will fail - no doubt with some useful error code like
“STATUS_DISK_FULL”.
I don’t see how you make this paradigm work in the real world without
enforcing it everywhere uniformly - does DAV enforce this limit? How
about the NFS server (in Vista, right?) I bet SFM didn’t enforce this
either (it probably enforced whatever the Macintosh limitation was.)
And of course the POSIX environment probably wouldn’t be POSIX compliant
if you enforced the MS-DOS max-path. As long as there is ANY way to
create such a path, you can’t make your own applications that enforce
the MS-DOS environment work properly in all situations.
Thus, I would suggest that the only way to make this work right really
is to use the OS level limit. We can’t fix the existing broken software
but we can make new software work right and eventually the world will
become a better place. As enough software reaches a point that it works
with full path names, the scales will tip and old obsolete applications
will “go away”.
If you want to do something really screwed up, try creating long path
names with cmd.exe and then using “cd” by the short name and repeating
this process - in this way you CAN create very deep directories even
with the lowly command shell.
For anyone writing security logic (AV, anti-malware) it’s important to
always use the OS level maximum path length. Otherwise I can hide
things a few k characters deep and make it tough (or impossible) to
remove, especially if I turn off short file name generation. Of course,
I’ve also embedded lots of non-printable characters, overlaid it with
different versions that only differ in case, and anything else I can
consider to make it damned tough to find. Of course, my real files are
buried in the System Volume Information directory and I open them by
object ID. 
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Friday, May 12, 2006 5:59 PM
To: ntfsd redirect
Subject: Re: [ntfsd] hiding directories and files using OS level support
features [was: sid and process name lenghts]
Tony Mason wrote:
Were I writing an application, I’d be cognizant of this possibility
because it leads to an unsatisfactory user experience. However, I’ve
been thoroughly “set right” by others within this group - being
advised
that it is perfectly reasonable for an application to exhibit
mysterious
behavior by not allowing users to open paths that can actually be seen
and manipulated by Explorer.
Explorer should prevent this or at least warn the user.
Either the APIs and constants should set MAX_PATH higher, or Explorer
should
limit it. Having two completely independent limits is the bug.
It’s not ‘mysterious’ behaviour - it’s the expression of a basic
contradiction
within the OS. Vista is a good chance to fix this…
In my own software I refuse to create files deeper than MAX_PATH
precisely
because such files would then be unable to be opened by the majority of
software. cmd.exe can’t even read them… I consider such directory
structures invalid.
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com