FindFirstFileExW and MAX_PATH
Egbert Nierop
I find it so interesting, that even a 64 bit OS, still uses that API,
limited to 260 (249 in fact) characters for directories and files.
FindFirstFileExW tells us about the \\?\ prefix, to overcome that limit, BUT
the WIN32_FIND_DATA structure, contains just 260 characters for the
cFilename section! :)
Is there an elegant alternate way to recursively have no MAX_PATH limit
while finding the directories
ps: My solution needs to be generic and I don't want to sell 'no cannot be
done' the customer.
Remy Lebeau
"Egbert Nierop" <egbert...@nospam.invalid> wrote in message
news:eRuk1nyT...@TK2MSFTNGP05.phx.gbl...
> I find it so interesting, that even a 64 bit OS, still uses that API,
> limited to 260 (249 in fact) characters for directories and files.
The complete path and filename together is limited to MAX_PATH characters by
default, yes.
> FindFirstFileExW tells us about the \\?\ prefix, to overcome that
> limit, BUT the WIN32_FIND_DATA structure, contains just
> 260 characters for the cFilename section! :)
The cFilename member receives just the filename, not the complete path
leading up to the filename. When '\\?\' is used, individual components of a
path (aka each subfolder and file name) are each limited to 255 characters
max. So receiving such a filename still fits within a buffer of MAX_PATH
size regardless of whether '\\?\' is used or not.
Gambit
Egbert Nierop
"Remy Lebeau" <no....@no.spam.com> wrote in message
news:OHut%23wyTI...@TK2MSFTNGP04.phx.gbl...
I _know_ this, thanks anyway.
My question is, is there any workaround? Because of filenames are really 65K
in theoretical length, or foldernames, it should be possible to enumerate
through them.
The question why someone would like to do this, is not here of course, I
want to reach that without limits :)
Let me ask it otherwise.
Is there a lower level routine available to enumerate through folders/files?
Alexander Grigoriev
"Egbert Nierop" <egbert...@nospam.invalid> wrote in message
>
>> The cFilename member receives just the filename, not the complete path
>> leading up to the filename. When '\\?\' is used, individual components
>> of a path (aka each subfolder and file name) are each limited to 255
>> characters max. So receiving such a filename still fits within a buffer
>> of MAX_PATH size regardless of whether '\\?\' is used or not.
>
> I _know_ this, thanks anyway.
>
> My question is, is there any workaround? Because of filenames are really
> 65K in theoretical length, or foldernames, it should be possible to
> enumerate through them.
Workaround for what, again? cFilename is just a _filename_, means last
component of the path, not _full path_. A _filename_ only ever ever goes up
to 256 WCHARs. You can only have a problem if you use FindFirstFileA, and
the filename takes more bytes because of MBCS.
Jochen Kalmbach [MVP]
> I _know_ this, thanks anyway.
>
> My question is, is there any workaround? Because of filenames are really
> 65K in theoretical length, or foldernames, it should be possible to
> enumerate through them.
????
File names are restricted to "255" chars!
See: http://msdn2.microsoft.com/en-us/library/aa365247.aspx
<quote>
The Unicode versions of several functions permit a maximum path length
of approximately 32,000 characters composed of components up to 255
characters in length. To specify that kind of path, use the "\\?\" prefix.
</quote>
A *component* is restricted to 255 characters!
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Volodymyr Shcherbyna
look at
http://msmvps.com/blogs/v_scherbina/archive/2007/07/15/undeletable-files-amp-folders-in-windows-xp-sp2.aspx
--
Volodymyr
NG tips:
http://msmvps.com/blogs/v_scherbina/pages/microsoft-newsgroups-tips.aspx
"Egbert Nierop" <egbert...@nospam.invalid> wrote in message
news:eRuk1nyT...@TK2MSFTNGP05.phx.gbl...
Egbert Nierop
"Volodymyr Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:ebtWpj8T...@TK2MSFTNGP04.phx.gbl...
> Even windows shell is not actually able to browse over long pathes, take a
> look at
> http://msmvps.com/blogs/v_scherbina/archive/2007/07/15/undeletable-files-amp-folders-in-windows-xp-sp2.aspx
>
Yes, it's funny that I renamed a file using MoveFileW to a name with 280
characters. :)
FindNextFile now cannot retrieve the name :)
Alexander Grigoriev
though.
But you can use it in commands issued in cmd.exe.
"Volodymyr Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:ebtWpj8T...@TK2MSFTNGP04.phx.gbl...
Volodymyr Shcherbyna
created using CreateFileW with extra long path (the case I describe in my
post entry).
Eset Nod32 perfectly scans the "long-long" dir and checks the files inside
it for viruses. I did not investigate, how this is done, but this is
possible.
--
Volodymyr
NG tips:
http://msmvps.com/blogs/v_scherbina/pages/microsoft-newsgroups-tips.aspx
"Egbert Nierop" <egbert...@nospam.invalid> wrote in message
news:ONzPOf%23TIH...@TK2MSFTNGP06.phx.gbl...
Volodymyr Shcherbyna
FileBothDirectoryInformation, and then step-by-step constructing the path by
chunks, returned from FILE_BOTH_DIR_INFORMATION::FileName.
--
Volodymyr
NG tips:
http://msmvps.com/blogs/v_scherbina/pages/microsoft-newsgroups-tips.aspx
"Volodymyr Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:ecnFiCUU...@TK2MSFTNGP05.phx.gbl...
Remy Lebeau
"Egbert Nierop" <egbert...@nospam.invalid> wrote in message
> My question is, is there any workaround?
A workaround for what, though? You are worried about cFilename being too
small when '\\?\' is used, and I have tried to explain to you that is not
the case. cFilename will contain ONLY a single folder/file name, not a full
path. Even when '\\?\' is used, a folder/file name cannot exceed 255
characters, which will fit just fine inside of cFilename, which can hold 260
characters.
> Because of filenames are really 65K in theoretical length, or
> foldernames, it should be possible to enumerate through them.
The OVERALL length of a full path can be that long when '\\?\' is used, yes.
But the sizes of the INDIVIDUAL portions of the path cannot exceed 255
characters each. Let's say you have a long path:
"c:\long folder here\another long folder here\filename.ext"
"long folder here", "another long folder here", and "filename.ext" are EACH
limited to 255 characters max. As you are enumerating through a folder
hirearchy, each of those pieces fits inside of cFilename just fine.
If you enumerate the contents of "c:\", cFilename will contain just "long
folder here", not "c:\long folder here".
Enumerating "c:\long folder here", cFilename will contain just "another long
folder here", not "c:\long folder here\another long folder here".
Enumerating "c:\long folder here\another long folder here", cFilename will
contain just "filename.ext", not "c:\long folder here\another long folder
here\filename.ext".
To enumerate a subfolder in general, regardless of whether "\\?\" is used,
simply append cFilename's current value to whatever path you provide as
input to FindFirstFile(). In other words, something like the following
pseudo-code:
EnumFolder(L"\\\\?\\c:\", L"*.ext");
void EnumFolder(LPCWSTR Path, LPCWSTR Mask)
{
HANDLE hFile = FindFirstFileW(Path + Mask, &ffd);
if( hFile != INVALID_HANDLE_VALUE )
{
do
{
if( ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY )
{
// Path + ffd.cFileName is a folder ...
EnumFolder(Path + ffd.cFileName + "\\", Mask);
}
else
{
// Path + ffd.cFileName is a file instead ...
}
}
while( FindNextFile(hFile, &ffd) );
FindClose(hFile);
}
}
> Is there a lower level routine available to enumerate through
> folders/files?
See above.
Gambit