> Easy way to understand is to create a file with name greater then MAX_PATH on win7 (from either
explorer or cmd). It won’t allow you to do so.
Try “md” and then “cd” many times in CMD
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> what is so different about your file system that you think you need to change the behavior of explorer for it ?
The driver would be like useless, if user can’t copy his files (that have path greater than MAX_PATH) to windows. If user can’t read those files.
Don’t want to rely on windows restrictions.
Something has to be done like rename a file with lengthy names, or invalid characters that NTFS don’t support.
e.g. Just modify the lengthy file names to something smaller, modify the invalid characters (* : ? |) to underscore “_” or hyphen “-”.
@Maxim, md create a directory, it won’t allow you either (my test on win8) to create a longer directory than MAX_PATH
The old NTFS concept of “short file name” addressed a similar problem in
maintaing backward compatibility with 8.3 naming conventios. Ultimately,
in the ReFS fie system, it was abandoned, mostly because of the perormance
issues. Prior to that, it was limited to forming semi-recognizable named
only for the first four files; the remaining files that might conflict
were simply assigned what appeared to be random numbers. So, asuming you
can do the intercepts you want, you’ve got a two-way mapping problem
whoseperformance impact can be significant. Whether it is significant in
the context of your domain depends on how much this is needed. NTFS stord
the sort name as part of the file name record, but it really is limited to
8.3. So you would have to allow for your own kind of “short name” and in
addition the problem of how to anticipate the maximum path that might be
formed. Overall, you have a very complex problem with serious pitfalls.
It may not have an acceptable solution. Getting the filenames to have a
MAX_PATH limit for te entire path down to the fiename level may be
unsolvable.
joe
Thank you Peter for explaining the point more.
My FILE SYSTEM can work on UNIX/LINUX/Mac. They don’t have such
limitations, and I am writing the FILE SYSTEM driver for WINDOWS.Any file whose path is greater then MAX_PATH can’t be opened on my FILE
SYSTEM supported volume, nor be copied. (All create operation fails, even
though I don’t fail them at my FILE SYSTEM DRIVER, but they get failed at
OS level)So the goal is actually to open the file whose path is greater to
MAX_PATH.@Daniel
> You are aware that your filter will never see names longer than
> MAX_PATH from explorer ?No I am not aware of this, and I don’t think this could be the case.
Because I do get the full path (greater than 255 characters) on my FILE
SYSTEM driver to open the files (So could the filter driver get).
So if I write a Filter Driver and modify/shorten the file names in
PostCreate (if possible, I don’t know how to do it, as I’m not too
familair with Filter Drivers)
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Hi Ladislav Zezula,
The file system I’m writing does have support for file name length greater
than what NTFS supports. So there is no question what File system supports
or not.The question is, what explorer.exe and/or other windows application
support (cmd.exe etc).These application don’t support file full path names greater than
MAX_PATH.
Easy way to understand is to create a file with name greater then MAX_PATH
on win7 (from either explorer or cmd). It won’t allow you to do so.Good point, I can use some mapping, like short file names.
Now is this possible, that I show Win32 names (long format names) to
explorer.exe and explorer.exe if can’t open the long format request for
short names?Or explorer.exe directly request for short names rather than going for
normal long names?
I had sent a reply earlier that said this may be an unsolvable problem,
but I was hoping you had thought this out a bit. Assume that you are
willing to pay the performance penalty and use an 8.3 short name
conversion, what happens when your path has more than 28 directories in
it? It now exceeds MAX_PATH, And you haven’t even gotten to the filename.
This would mean that you would have to have a short name that was an
alias for two or more directory steps, and these would have to be
dtermined in realtime based on the actual dynamic path presented. This
was why I said the problem may not be solvable. You need a “short name”
for a file which is m.n, where m+n < MAX_PATH. But since, to determine
this name, you have to know the “short names” of all the directories
starting from the root. If the user copies the file to a deeper or
shallower subtree, which may or may not contain a conflicting name, how do
you resolve the naming? A complex problem.
joe
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>> what is so different about your file system that you think you need to
> change the behavior of explorer for it ?
The driver would be like useless, if user can’t copy his files (that have
path greater than MAX_PATH) to windows. If user can’t read those files.Don’t want to rely on windows restrictions.
Something has to be done like rename a file with lengthy names, or invalid
characters that NTFS don’t support.e.g. Just modify the lengthy file names to something smaller, modify the
invalid characters (* : ? |) to underscore “_” or hyphen “-”.
Insufficient. It is FAR more complex than that. If you want Winows to
read the file “a*B” (which is not the same as “A*b”) then yes, you could
open “A_B”, but the which of tbe two files do you open? And for your
suggested solution, how would you handle “a:B”, “A?B” and “a|b”? And what
if there is already “A_B”? What if there were 28 directories in the path,
each one being 8.0 in length (fewer if 8.n for n >= 1; more, if m.n for
arbitrary m,n such that m+n <= 11, and what happens if a directory is
renamed?
What if my app opens “a*b.c” and the output should be “a*b.obj”? And the
other side of the interface is expecting “a*b.obj”. And you also want to
compile the file “a_b.c” and “a?b.c”, and have the filesystem on the other
side do the linking. So you could do something like HTML, convert the
symols, such as converting “a*b” to “a&42;b” which means that if you have
a file called “a&b” it turns into “a&b”. The advantage of this
transformation is that it is bidirectional and isomorphic. It still
doesn’t solve the MAX_PATH problem, but at least it is a usable solution
to the illegal-character problem.
I had thought you would have considered all these issues, but your idea of
mapping forbidden characters to a single valid character shows a rather
superficial analysis of the problem.
joe
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>>> You are aware that your filter will never see names longer than
>>> MAX_PATH from explorer ?
OpenOffice says that the LoadLibrary() API won’t handle anything longer
than MAX_PATH, even if you use the Unicode long path method. Excerpt
from main/sal/osl/w32/module.cxx comment:
“LoadLibrary cannot handle file names which exceed 260 letters. In case
the path is to long, the function will fail. However, the error code can
be different. For example, it returned ERROR_FILENAME_EXCED_RANGE on
Windows XP and ERROR_INSUFFICIENT_BUFFER on Windows 7 (64bit)”
> @Maxim, md create a directory, it won’t allow you either (my test on win8)
to create a longer directory than MAX_PATH
md test1
cd test1
md test2
cd test2
…
cd test49
md test50
now open c:\test1\test2.…\test50\whatever.txt
Note that this complete path exceeds MAX_PATH .
MAX_PATH limits the filename length in the current working directory, but
it also limits the, well, maximum path length, if you aren’t getting a
file from the current working directory.
joe
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> OpenOffice says that the LoadLibrary() API won’t handle anything longer than MAX_PATH,
even if you use the Unicode long path method. Excerpt from main/sal/osl/w32/module.cxx comment:
Confirmed, LoadLibraryW returns NULL nd GetLastError is ERROR_FILENAME_EXCED_RANGE
(Windows XP SP3)
L.
@Joe, the point here is just to make sure the longer file names are reduced to a smaller names.
When the file full path (at IRP_MJ_CREATE, we get full file path from IoStackLocation->FileObject->FileName) exceeds the MAX_PATH, we can open the file at the file system level, returning FILE_OPENED, and setting other structures as required. So at the same point some mechanism to decrease (A good word could be rename) the original file name.
Let suppose, we can’t by-pass the explorer.exe because it is the limitation for it. But we can pass the limitation at the copy operation.
e.g. a file on the disk is (F:\dir.…\file1.txt)
When user try to copy this file, that has full path name exceeds MAX_PATH length, simply rename it to D:\dir\file1.txt.
Moreover, if the file1.txt exists on the target, it is the target’s file systems responsibility to respond on its IRP_MJ_CREATE that the file exists in the form of FILE_EXISTS return code. It will automatically prompts for file exists/rename dialog to ask user to modify the name.
Lets put it in this way.
How can I bring the file replace/rename dialog, when I can’t copy a file due to MAX_PATH issue?
> Let suppose, we can’t by-pass the explorer.exe because it is the limitation for it.
It is a limit for kernel32.dll and whole Win32, not only the shell.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> @Maxim, md create a directory, it won’t allow you either (my test on win8) to create a longer directory
I mean - use relative md. Like:
c:\VeryLongPath>md NextDir1
c:\VeryLongPath>cd NextDir1
c:\VeryLongPath\NextDir1>md NextDir2
And so on.
–
Maxim S. Shatskih
Windows DDK MVP
> now open c:\test1\test2.…\test50\whatever.txt<
Try opening “\?\c:\test1\test2.…\test50\whatever.txt” instead.
> > now open c:\test1\test2.…\test50\whatever.txt<
Try opening “\?\c:\test1\test2.…\test50\whatever.txt” instead.
I was naming the file, not the path required for CreateFile to get to it.
The point being that the resulting path exceeds MAX_PATH even though no
individual component is too long. So any solution that merely shortens
filenames is not going to handle this case.
joe
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer