Using ZwQueryDirectoryFile and RtlIsNameLegalDOS8Dot3 for fast SFN -> LFN conversion

NTFSD
1

Hey guys,

Reading through the archives there has been a lot of talk about using ZwQueryDirectoryFile to get the LFN of a path, in which most people recommend doing a query for each part of the path. I have some questions on this:

  1. Is it faster to check RtlIsNameLegalDOS8Dot3 and if true, then and only then call ZwQueryDirectoryFile?

  2. Do RtlIsNameLegalDOS8Dot3 and ZwQueryDirectoryFile have the same behavior on W2K as WXP and above? I have read conflicting posts about this. I need this same functionality to work on W2K and above.

  3. Can anyone point me to code snippets in the IFS kit (or even the Internet) that is using this approach, or alternatively does anyone have any of their own that would like to share?

I really need to figure a fast a clean way to expand the long file name within the kernel, and since GetLongPathName() isn’t exposed to me, I am having to find a good way to do this. Any other recommendations?

–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

2

> 1) Is it faster to check RtlIsNameLegalDOS8Dot3 and if true, then and only
then call ZwQueryDirectoryFile?

I believe so, I do this, I guess pretty much everyone does.

  1. Do RtlIsNameLegalDOS8Dot3 and ZwQueryDirectoryFile have the same
    behavior on W2K as WXP and above? I have read conflicting posts about this.
    I need this same functionality to work on W2K and above.

Interesting question, I dont know the answer. I use same calls for W2K and
W2K3 server products.

  1. Can anyone point me to code snippets in the IFS kit (or even the
    Internet) that is using this approach, or alternatively does anyone have any
    of their own that would like to share?

Sorry, nope.

I really need to figure a fast a clean way to expand the long file name
within the kernel, and since GetLongPathName() isn’t exposed to me, I am
having to find a good way to do this. Any other recommendations?

I would hazard a guess that Win32 GetLongPathName() does this but it might
cache SFN -> LFN translations. Neal tells us that the filter manager support
for file names caches these translations. If you want a fast translation
then caching seems to be a good plan. One other thing to think about is when
you build the name sometimes you have to use the name of
FileObject->RelatedFileObject …; if you happen to store the LFN say on a
per FileObject->FsContext basis then you might already know the result of
the translation for part of the path.