Tony Mason wrote:
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”.
Actually we can:
- Define MAX_PATH and its related constants to a realistic value.
- Fix the ANSI APIs - 99% of applications are ANSI. (from MSDN: ‘NTFS
file system supports paths up to 32768 characters in length, but only
when using the Unicode APIs’) - Make the runtime libraries conform to this value
- Recompile the applications
Steps 2 and 3 are the crucial ones. As long as CreateFile() and fopen()
enforce an arbitrary limit then there really isn’t any hope.
It’s equally frustrating for application developers to be forced to such
short pathnames.
There’s also the problem of well known filenames… you still can’t
create a file called con.txt for example (or prn.exe… there’s a list of
filenames that don’t work). Apparently the unicode hack works around
this, but then explorer can’t open the file! That’s just old DOS
compatibility cruft and really needs to die.
FYI - explorer is one of the ‘broken’ applications you mention - its
gets extremely random if you go over a 256 character path.
Create a folder called
123456788901234567898012345678901234567890123456788901234567898012345678901234567890123456788901234567898012345678901234567890123456788901234567898012345678901234567890
Enter that and create another folder with the same name in it. Total
pathname is about 320 characters.
Now select ‘new folder’ or try to create a document. oops.
Tony