I’m not sure whether the function used by the OS to generate short names
(RtlGenerate8dot3Name) is guaranteed to always return names containing ~. I
can’t find anything in the documentation and the disassembly looks rather
nasty :(, but from what I see (again, not 100% certain) it does seem to only
generate names with ~.
since you’re calling it from PostOpCreate (I assume you mean successful
creates here) I’m not sure why you’d not see the mount points not resolved.
I expect they’d be resolved by the IO manager by the time the IRP_MJ_CREATE
you’re looking at was issued.
as far as I can tell you can’t open a file by fileID or objectID over SMB
(I’m looking at the 2.2.13 SMB2 CREATE Request document on MSDN -> http://msdn.microsoft.com/en-us/library/cc246502(v=prot.13).aspx, which
states that for the FILE_OPEN_BY_FILE_ID create option “This bit SHOULD be
set to 0 and the server MUST fail the request with a STATUS_NOT_SUPPORTED
error if this bit is set.<34>” ).
Yes, we are calling it from PostOpCreate. Dejan mentioned earlier that “Normalized names also resolve mount points.”. Hence, I thought that opened name do not resolve it. I will confirm this though.
RtlGenerate8dot3Name happens to always generate names with ~ in them for now. This is an implementation detail that should not be relied upon to remain true. The algorithm for generating short names has changed in the past, and may change in the future.
See the “Remarks” section of http://msdn.microsoft.com/en-us/library/windows/hardware/ff544633(v=vs.85).aspx for the definitions of what constitutes a “normalized”, “opened”, and “short” name. That section notes that mount points are not resolved in a query for FLT_FILE_NAME_OPENED. After all, the “opened name” is the name that the caller used to open the file. If the Filter Manager resolved mount points in a query for the opened name, it would no longer be the name the caller used.
Mount points do of course get resolved during the open so that the actual object being opened can be accessed, but that doesn’t have a bearing on the name string you get back when requesting the opened name from Filter Manager.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
Wait, so my assumption up to this point has been that that opened name is
not exactly “the name the caller used” but rather the “the name the IO
manager used when issuing the IRP_MJ_CREATE”. So for a case where you have
\Device\HarddiskVolume1\foo.txt which reparses to
\Device\HarddiskVolume2\bar.txt, the name the caller used might have been
“c:\foo~1.txt” or “\Device\HarddiskVolume1\foo~1.txt” and the opened name
for the first IRP_MJ_CREATE would be “\Device\HarddiskVolume1\ foo~1.txt”
and the opened name for the second IRP_MJ_CREATE would be
“\Device\HarddiskVolume2\bar.txt”. Is this not the case?
Yes, we are calling it from PostOpCreate. Dejan mentioned earlier that “Normalized names also resolve mount points.”. Hence, I thought that opened name do not resolve it. I will confirm this though.
I spent some time wading through NTFS. The documentation must be wrong (where it says that in an opened name "Mount points are not resolved. "). So you’re right, the reparse points are resolved in the opened name. This has to be the case because Filter Manager gets the opened name by sending a FileNameInformation query to the file system. NTFS, for example, services this by returning the name stored in its CCB (i.e. FsContext2 structure). That structure isn’t created until the create is about to be completed (after reparse processing), and the name it uses came from the FileObject during the create. If the FileObject didn’t have a no-reparse-points name in it then NTFS wouldn’t have been able to complete the open.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
What about in pre create? I didn’t think that mount points were resolved if
the request was for “opened name”.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Tuesday, August 21, 2012 3:26 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Mini filter peformance issues while accessing network
files
Alex,
I spent some time wading through NTFS. The documentation must be wrong
(where it says that in an opened name "Mount points are not resolved. ").
So you’re right, the reparse points are resolved in the opened name. This
has to be the case because Filter Manager gets the opened name by sending a
FileNameInformation query to the file system. NTFS, for example, services
this by returning the name stored in its CCB (i.e. FsContext2 structure).
That structure isn’t created until the create is about to be completed
(after reparse processing), and the name it uses came from the FileObject
during the create. If the FileObject didn’t have a no-reparse-points name
in it then NTFS wouldn’t have been able to complete the open.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
Thanks for looking into it! That’s pretty much what I thought was the case.
Bill, I think even in preCreate things are similar, except there are multiple preCreates for each open that traverses several mountpoints and so it’s harder to know if you’re in the final preCreate or not. If my understanding is correct, in order for FltMgr to actually return a name that’s not coming from the FILE_OBJECT it would have to look into the OPEN_PACKET to get it and I’m pretty sure it’s not doing that. So the name must have all the mountpoints resolved up to that point in the path, regardless of whether it’s in pre or postCreate.
In pre-create the name is built from the FILE_OBJECT for non-open-by-ID opens. Therefore mount points are not resolved in that case. So, as Alex noted, you’d have to know if you’re in the final pre-create to know whether the name you got back was completely free of mount points. Furthermore, if it is a relative open then Filter Manager queries the name from FILE_OBJECT.RelatedFileObject and then adds the portion of the path from the FILE_OBJECT. Since RelatedFileObject has to already be open for a relative open to work, the portion of the path that is covered by RelatedFileObject *does* have mount points resolved but the remainder doesn’t.
The moral of that story is: if you care about mount points wait until post-create before you go asking for an opened name.
BTW, for open-by-ID Filter Manager actually opens the file (bypassing lower filters), asks for the name, and closes the file. This doesn’t involve mount points, but I’m including it here for completeness.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
I’m curious (since you’ve been looking) how NTFS would resolve cross-volume symbolic links?
In fact, we’ve just been discussing this very issue (reparse points) because we’re looking at what happens when we start encrypting the data within the symbolic link (we’re encrypting the names of files and directories, so the question of what we should return here gets quite interesting actually).