Hi guys,
I needed to query short file name information for path elements for my
open file and faced with some oddities using ZwQueryInformationFile()
and ZwQueryDirectoryFile() routines for folder on an
NTFS volume (running on Windows XP SP2).
1. ZwQueryInformationFile() returns STATUS_OBJECT_NAME_NOT_FOUND for
folder, but it perfectly, for example, works out for
folder. And it works fine for all other long-name
folders. I have never seen such behavior for this routine, especially
described anywhere in MS docs.
2. ZwQueryDirectoryFile() routine with FileBothDirectoryInformation
fails with STATUS_BUFFER_OVERFLOW when called with fixed size buffer,
i.e. with sizeof( FILE_BOTH_DIR_INFORMATION ), although DDK says that if
the structure created for the first entry found is too large to fit into
the output buffer, only the fixed portion of the structure is returned
(the fixed portion consists of all fields of the structure except the
final FileName string). But in my case all fixed output structure fields
remain the same as they were before this call. But even if I provide
sufficient buffer, this routine doesn’t return a short file name for
folder anyway. At least there are two oddities for this
routine in my case. But then I wrote some test console application which
uses GetShortPathName() and FindFirstFile() routines, but these routines
still return no short file name info. GetShortPathName() returned a full
long name , and FindFirstFile() returned nothing at all
in the cAlternativeFileName field of the WIN32_FIND_DATA structure.
I’m totally surprised and really don’t know how to distinguish between
regular error conditions and such oddities. Are all described situations
normal for these routines?
Thanks beforehand, any explanations and suggestions will be highly
appreciated.
With best regards,
Konstantin Manurin
System Programmer
mailto:xxxxx@gmail.com
> routine in my case. But then I wrote some test console application which
uses GetShortPathName() and FindFirstFile() routines, but these routines
still return no short file name info. GetShortPathName() returned a full
long name
Looks like the \Program Files folder just has no short file name created. These
names are not mandatory I think.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>
Looks like the \Program Files folder just has no short file name created. These
names are not mandatory I think.
It seems to be the truth. Funny but on my home notebook running Windows
XP SP2 Home Edition it works fine, but I don’t exactly remember a type
of file system (FAT32 or NTFS) used.
> 1. ZwQueryInformationFile() returns STATUS_OBJECT_NAME_NOT_FOUND for
folder, but it perfectly, for example, works out for
> folder. And it works fine for all other long-name
> folders. I have never seen such behavior for this routine, especially
> described anywhere in MS docs.
>
Oh, I totally forgot to say that I call ZwQueryInformationFile() with
FileAlternateNameInformation parameter.
With best regards,
Konstantin Manurin
System Programmer
mailto:xxxxx@gmail.com
I have no idea if this the case, but, given that the generation of 8.3
names can be disabled, I wonder if this problem only affects those
folders that were created during setup or something like that, and then
generation got reenabled. If you think this might be worth checking
out, see what happens with “Documents and Settings?”
>> xxxxx@gmail.com 2007-01-10 14:22 >>>
Looks like the \Program Files folder just has no short file name
created. These
names are not mandatory I think.
It seems to be the truth. Funny but on my home notebook running
Windows
XP SP2 Home Edition it works fine, but I don’t exactly remember a type
of file system (FAT32 or NTFS) used.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You can turn off short filename creation for Ntfs with a registry setting, I
think.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Konstantin Manurin” wrote in message
news:xxxxx@ntfsd…
>
>>
>> Looks like the \Program Files folder just has no short file name created.
>> These
>> names are not mandatory I think.
>>
> It seems to be the truth. Funny but on my home notebook running Windows
> XP SP2 Home Edition it works fine, but I don’t exactly remember a type
> of file system (FAT32 or NTFS) used.
>
Use
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCre
ation with a value of 1 to disable.
See
http://technet2.microsoft.com/WindowsServer/en/library/61cd1970-5254-47c
2-96d4-a66c780446381033.mspx?mfr=true (which worked today when I tried
it, but is likely to stop working within 30 minutes based upon the
behavior of the Microsoft URL randomizer.)
In addition, this is likely to become the only option in the not too
distant future (e.g., NTFS will stop generating short names) - build
your products NOW so they work with long file names and do not rely upon
short names.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
As well some file systems you may or may not encounter don’t implement
them at all. As Tony said, don’t build your products on non-portable
assumptions!
Tracy
On Wed, 10 Jan 2007, Tony Mason wrote:
Use
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCre
ation with a value of 1 to disable.
See
http://technet2.microsoft.com/WindowsServer/en/library/61cd1970-5254-47c
2-96d4-a66c780446381033.mspx?mfr=true (which worked today when I tried
it, but is likely to stop working within 30 minutes based upon the
behavior of the Microsoft URL randomizer.)
In addition, this is likely to become the only option in the not too
distant future (e.g., NTFS will stop generating short names) - build
your products NOW so they work with long file names and do not rely upon
short names.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually, following up on Tracy’s follow-up, note that this behavior is
true back in NT 3.1 (HPFS only used long names, and did not generate
short names) so this is not a “change” in behavior, but rather something
you might not have observed.
Others have previously found that you can actually cause no short name
generation to occur even without these options on NTFS under some
circumstances. And imagine what happens the first time someone attached
a disk to a computer with your product where the NTFS file system was
generated on a different computer?
Thus, the registry parameter is sufficient but not necessary to see this
“in the real world.”
And that’s ignoring the very real possibility that you might encounter
file systems that don’t generate 8.3 compatible names.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
> I have no idea if this the case, but, given that the generation of 8.3
names can be disabled, I wonder if this problem only affects those
folders that were created during setup or something like that, and then
generation got reenabled. If you think this might be worth checking
out, see what happens with “Documents and Settings?”
Martin, thank you for this advice.
I checked these routines in my virtual FS driver and my console test
application for and got the same results - no
short names were generated, to be exact, Win32 test application simply
returned a long file name instead of short one. It seems that the Win32
layer is able to gracefully process such oddity (in GetShortPathName()
routine).
WBR,
Konstantin Manurin
System Programmer
> Actually, following up on Tracy’s follow-up, note that this behavior is
true back in NT 3.1 (HPFS only used long names, and did not generate
short names) so this is not a “change” in behavior, but rather something
you might not have observed.
Others have previously found that you can actually cause no short name
generation to occur even without these options on NTFS under some
circumstances. And imagine what happens the first time someone attached
a disk to a computer with your product where the NTFS file system was
generated on a different computer?
Thus, the registry parameter is sufficient but not necessary to see this
“in the real world.”
And that’s ignoring the very real possibility that you might encounter
file systems that don’t generate 8.3 compatible names.
Tony, thank you very much for your detailed explanation.
I’d also like to briefly add some more precise definitions of my purpose.
I need short file names support in my virtual FS/FS filter driver only
for parsing and processing all incoming file path names in case these
incoming paths contain short path name elements, but of course I
primarily use only long path names. And I cannot assume a target file
system what my driver will be attached to. So it would be good to know
whether I can use a short path name element or if not its long counterpart.
And I’m kind of surprised at ZwQueryDirectoryFile() routine behavior.
Why doesn’t this routine fill in output structure fixed fields? Although
MS DDK implies quite different behavior. After all,
ZwQueryInformationFile() (IoQueryFileInformation()) routine works just
as it’s described in DDK docs, it returns an error status and fills all
fixed structure fields including the FileNameLength field which allows
to calculate a total size of an output buffer. But
ZwQueryDirectoryInformation() routine with FileBothDirectoryInformation
parameter doesn’t even fill the FileNameLength field, so I cannot
evaluate a total size of an output buffer.
Once again many thanks for your explanations.
WBR,
Konstantin Manurin
System Programmer
Thank you all guys for detailed and helpful explanations and suggestions.
WBR,
Konstantin Manurin
System Programmer
mailto:xxxxx@gmail.com
No problem.
>> xxxxx@gmail.com 2007-01-11 07:13 >>>
I have no idea if this the case, but, given that the generation of
8.3
names can be disabled, I wonder if this problem only affects those
folders that were created during setup or something like that, and
then
generation got reenabled. If you think this might be worth checking
out, see what happens with “Documents and Settings?”
Martin, thank you for this advice.
I checked these routines in my virtual FS driver and my console test
application for and got the same results - no
short names were generated, to be exact, Win32 test application simply
returned a long file name instead of short one. It seems that the
Win32
layer is able to gracefully process such oddity (in GetShortPathName()
routine).
WBR,
Konstantin Manurin
System Programmer
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Do not use ZwQueryDirectoryFile. Instead, take the pathname provided to you
and open all its dirs in a usual way. You can then query each dir for its
short/long name, and thus convert the whole path to short/long form.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Konstantin Manurin” wrote in message news:xxxxx@ntfsd…
>
> > Actually, following up on Tracy’s follow-up, note that this behavior is
> > true back in NT 3.1 (HPFS only used long names, and did not generate
> > short names) so this is not a “change” in behavior, but rather something
> > you might not have observed.
> >
> > Others have previously found that you can actually cause no short name
> > generation to occur even without these options on NTFS under some
> > circumstances. And imagine what happens the first time someone attached
> > a disk to a computer with your product where the NTFS file system was
> > generated on a different computer?
> >
> > Thus, the registry parameter is sufficient but not necessary to see this
> > “in the real world.”
> >
> > And that’s ignoring the very real possibility that you might encounter
> > file systems that don’t generate 8.3 compatible names.
> >
> Tony, thank you very much for your detailed explanation.
>
> I’d also like to briefly add some more precise definitions of my purpose.
>
> I need short file names support in my virtual FS/FS filter driver only
> for parsing and processing all incoming file path names in case these
> incoming paths contain short path name elements, but of course I
> primarily use only long path names. And I cannot assume a target file
> system what my driver will be attached to. So it would be good to know
> whether I can use a short path name element or if not its long counterpart.
>
> And I’m kind of surprised at ZwQueryDirectoryFile() routine behavior.
> Why doesn’t this routine fill in output structure fixed fields? Although
> MS DDK implies quite different behavior. After all,
> ZwQueryInformationFile() (IoQueryFileInformation()) routine works just
> as it’s described in DDK docs, it returns an error status and fills all
> fixed structure fields including the FileNameLength field which allows
> to calculate a total size of an output buffer. But
> ZwQueryDirectoryInformation() routine with FileBothDirectoryInformation
> parameter doesn’t even fill the FileNameLength field, so I cannot
> evaluate a total size of an output buffer.
>
>
> Once again many thanks for your explanations.
>
> WBR,
> Konstantin Manurin
> System Programmer
>
Yes, I do it just like this. Simply I decided to query short path names
using ZwQueryDirectoryFile() when I failed to obtain them via
ZwQueryInformationFile() with FileAlternateNameInformation parameter (it
simply returned STATUS_OBJECT_NAME_NOT_FOUND).
But now I think it would be quite reliable method to check exactly this
status value and if it’s STATUS_OBJECT_NAME_NOT_FOUND (or
STATUS_OBJECT_PATH_NOT_FOUND, just in case), I will use a long path name
element instead of its short form. I suspect the Win32 layer do it this
way, for example, GetShortPathName() routine returns long path name
elements along with other short ones where it’s not possible to query them.
Once again many thanks for helpful suggestions.
WBR,
Konstantin Manurin
System Programmer
Do not use ZwQueryDirectoryFile. Instead, take the pathname provided to you
and open all its dirs in a usual way. You can then query each dir for its
short/long name, and thus convert the whole path to short/long form.
You need to observe GetShortPathName/GetLongPathName with filespy/filemon.
“Konstantin Manurin” wrote in message
news:xxxxx@ntfsd…
> Yes, I do it just like this. Simply I decided to query short path names
> using ZwQueryDirectoryFile() when I failed to obtain them via
> ZwQueryInformationFile() with FileAlternateNameInformation parameter (it
> simply returned STATUS_OBJECT_NAME_NOT_FOUND).
>
> But now I think it would be quite reliable method to check exactly this
> status value and if it’s STATUS_OBJECT_NAME_NOT_FOUND (or
> STATUS_OBJECT_PATH_NOT_FOUND, just in case), I will use a long path name
> element instead of its short form. I suspect the Win32 layer do it this
> way, for example, GetShortPathName() routine returns long path name
> elements along with other short ones where it’s not possible to query
> them.
>
> Once again many thanks for helpful suggestions.
>
> WBR,
> Konstantin Manurin
> System Programmer
>
>> Do not use ZwQueryDirectoryFile. Instead, take the pathname provided
>> to you
>> and open all its dirs in a usual way. You can then query each dir for its
>> short/long name, and thus convert the whole path to short/long form.
>>
>>
>
Yeah, that’s the real deal, thank you for this idea, I will certainly
check this out.
WBR,
Konstantin Manurin
System Programmer
You need to observe GetShortPathName/GetLongPathName with filespy/filemon.
> Yes, I do it just like this. Simply I decided to query short path names
> using ZwQueryDirectoryFile() when I failed to obtain them via
> ZwQueryInformationFile() with FileAlternateNameInformation parameter (it
> simply returned STATUS_OBJECT_NAME_NOT_FOUND).
>
> But now I think it would be quite reliable method to check exactly this
> status value and if it’s STATUS_OBJECT_NAME_NOT_FOUND (or
> STATUS_OBJECT_PATH_NOT_FOUND, just in case), I will use a long path name
> element instead of its short form. I suspect the Win32 layer do it this
> way, for example, GetShortPathName() routine returns long path name
> elements along with other short ones where it’s not possible to query
> them.