It seems that the OS doesn’t support it (windows OS).
Because the NTFS file path limits are “32,767 Unicode characters with each path component (directory or filename) commonly up to 255 characters long”.
But when I tried to create a file in the directory that exceeds the 255 characters. Windows explorer didn’t allow me.
Is there anyway to bypass it (keeping the fact that i’m working on kernel level File System driver)
> Because the NTFS file path limits are "32,767 Unicode characters with each
path component (directory or filename) commonly up to 255 characters
long".
Just side note: I believe it’s rather NT limit in general. NTFS can make
such long paths, but each path element (either directory or file name)
must be at the most 255 characters.
The limit of 32,767 Unicode characters is given by limit of UNICODE_STRING.
As the length of the string is given as 16-bit integer in bytes,
and each character has 2 bytes, that gives 0xFFFE / 2 = 7FFFF = 32767
characters.
Unless there is a way how to open/create file with a name given
in another structure than UNICODE_STRING.
We can create on NTFS, but explorer don’t allow us. So if we have to create a file full path greater than 255 characters, Explorer don’t allow us.
NTFS does support huge file path names (only one perticular instance of filename i.e. file or folder can only contain 255 characters)
@Ladislav Zezula
Yes NTFS does support the 32,767 Unicode Characters. But it is the explorer (OS has the limitation).
You need to use the Unicode version of CreateFile because the ANSI version
is limited to MAX_PATH characters. Also you need to prepend "\?" to the
path as explained in CreateFile documentation.
Well that is for sure that NTFS does use the 32,767 unicode chars for path, where as only contain 255 unicode chars for single file name (keeping the fact everything is file on NTFS).
The question here is not writing the user space application that works on longer file names.
The question is, how to by pass it, or how to modify it in the kernel (where i’m working on a kernel level file system driver)
As indicated by Ladislav, this isn’t a limitation of the file system and
it’s not a limitation of the API, if you use the correct naming, but it
is a limitation of the calling applications. There is no way to by-pass
this limitation within Explorer from kernel mode or otherwise. You can
write your own application which will utilize much longer names and
there are many applications which do but you can’t get around it in
Explorer as far as I understand it.
Well that is for sure that NTFS does use the 32,767 unicode chars for path, where as only contain 255 unicode chars for single file name (keeping the fact everything is file on NTFS).
The question here is not writing the user space application that works on longer file names.
The question is, how to by pass it, or how to modify it in the kernel (where i’m working on a kernel level file system driver)
Thanks Peter Scott,
So that mean I have to write a filter driver, that will look at the names longer then MAX_PATH and will have to alter them from there.
This is the solution that comes to my mind, and seems people agree with it, and no other means to bypass or modify the limitation.
If you want to ‘shorten’ the names from the underlying file system so
the files can be opened in Explorer then yes, you can mangle them that
way and modify directory enumerations, name queries and opens/creates.
But you would need to keep a cache of this mapping so that when Explorer
does open the file with the shorter name you know which to open. Of
course, you could translate the long names into their 8.3 short names
but this could be too restricting and give interesting results in
enumerations. Possibly store the shortened name in an ADS or something
could work but again, you’ll have a bunch of edge cases to deal with in
doing this name mangling.
Thanks Peter Scott,
So that mean I have to write a filter driver, that will look at the names longer then MAX_PATH and will have to alter them from there.
This is the solution that comes to my mind, and seems people agree with it, and no other means to bypass or modify the limitation.
This sounds like a nonsensical thing to do. You are just running into a
limitation of the API on which explorer relies. Why do you think you need to
“bypass or modify” the limitation ? You are aware that your filter will
never see names longer than MAX_PATH from explorer ? What is the problem
that you think you are having that you want to solve ?
//Daniel
wrote in message news:xxxxx@ntfsd…
Thanks Peter Scott,
So that mean I have to write a filter driver, that will look at the names
longer then MAX_PATH and will have to alter them from there.
This is the solution that comes to my mind, and seems people agree with it,
and no other means to bypass or modify the limitation.
Right, that’s what I thought at first until I reread the original post.
I think there is an underlying file system that contains files, created
by some other tool or application, whose names are longer than what
Explorer can handle. The OP wants to be able to access this name space
and modify it via Explorer hence the need for the filter to modify names
on the way ‘to’ user land.
This sounds like a nonsensical thing to do. You are just running into a
limitation of the API on which explorer relies. Why do you think you
need to “bypass or modify” the limitation ? You are aware that your
filter will never see names longer than MAX_PATH from explorer ? What is
the problem that you think you are having that you want to solve ?
//Daniel
> wrote in message news:xxxxx@ntfsd…
> Thanks Peter Scott,
> So that mean I have to write a filter driver, that will look at the
> names longer then MAX_PATH and will have to alter them from there.
> This is the solution that comes to my mind, and seems people agree
> with it, and no other means to bypass or modify the limitation.
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.
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)
Any file whose path is greater then MAX_PATH can’t be opened on my FILE
SYSTEM supported volume, nor be copied.
NT file systems should be able to open any file whose total path
length is less than 32767 characters. MAX_PATH is a relic from the
past (was 80 characters in DOS and is 260 in Win32).
Your file system driver gets a parsed name (i.e. device name cut)
in form of an UNICODE_STRING. Name length limit is given by UNICODE_STRING
itself, like I said before.
If an application does not support file names that long, you can only
do some file name mapping. We in Windows have our (in)famous short file
names, where every path fragment gets replaces by 8.3 file name.
Example:
C:\Program Files\Common Files\Microsoft Shared
can be
C:\PROGRA~1\COMMON~1\MICROS~1
This is what your file system driver can do. Maybe this is what you
are looking for?
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?
> 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?
Well there are 2 ways how an application (e.g. explorer.exe) can request
file name - Directory Enumeration and File Name Query
Both of these have a standard interfaces (class codes and structure
definitions)
for returning either long name, short name or both. You, as a file system,
just need to support them all.
For more info, refer to NtQueryDirectoryFile or NtQueryInformationFile.
I am still not getting it. Here is something that I have not understood: no
matter what filesystem we are using, NTFS, FAT or other, explorer is not
able to handle long path names so you cannot do file management on them. The
question I have is, since this is not possible with any filesystem, what is
so different about your file system that you think you need to change the
behavior of explorer for it ?
In my book, it is never a good idea to tune a fundamental base component
such as a fs driver or a filter only to accomodate the shortcomings and
limitations of one specific high-level application, even if that’s called
explorer.
I think your time would be better spend in developing a new file management
utility rather than opening this can of worms. Because let’s face it, if
your fs supports path names up to 32767 chars and explorer can only display
and handle 255 you will not be able to do any type of file management on
long path names in practical terms even if a mapping to a shorter pathname
exists to fake it, the long path name will be lost. To get an idea, try to
access a FAT with long file names on it from a (real) MS-Dos box. You still
can access the files with their 8.3 names but only in a read-only manner
because LFN cannot written out.
Then suppose, on Windows 9 explorer only handles 128 characters to
accomodate the limitations of the latest gadget which also needs to run
Explorer. What will you do, update your filter driver again ?
> 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)
How can you expect your filter or fs to get called by explorer with long
names that it does not support ?