Hi Ted,
The thing to do in this case is to query the name of
IrpSp->Parameters.SetFile.FileObject, and append the final name
component from IrpSp->Parameters.SetFile.FileObject->FileName. This
also works for the relative rename case.
Simply using IrpSp->Parameters.SetFile.FileObject->FileName will give
you too much name with a mount point and too little name with a subst’ed
drive letter.
You are wise to be wary of the name in the file object. Fat can use
this because it fills in the name during SL_OPEN_TARGET_DIRECTORY
IRP_MJ_CREATEs. Ntfs does it differently, so this would not be a
general solution.
I believe OSR is going to do an update on this problem in a future NT
Insider. Tony?
- Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Friday, January 17, 2003 12:38 PM
To: File Systems Developers
Subject: [ntfsd] Determining correct rename target path for
fully-qualified rename case
For this discussion a fully-qualified rename is defined by:
IrpSp->Parameters.SetFile.FileObject != NULL &&
FileRenameInformation.RootDirectory == NULL
The UnicodeString pointed to by FileRenameInformation.FileName does
indeed contain the full path name of the target file as specified by the
caller. What it does not contain is any resolved reparse points (mount
points & directory junctions). If one needs the “real” path name of the
target (after all the source path was resolved by the CREATE) this gets
more complicated.
I was curious about how the FS drivers handle these cases… Upon
examining the FastFat example in the W2K IFS kit, I noticed all it does,
in this case, is to use the FileName of the attached FileObject
(IrpSp->Parameters.SetFile.FileObject->FileName, which as it turns out
is already resolved. How can this be? We are supposed to be distrustful
of the FileName field in post-CREATE FileObjects. In this case I find
that the full path of the target name is laid out in a very convenient
manner. Namely, the FileName.Length value spans the target path and the
FileName.MaximumLength spans the entire target including the leaf-name.
As an extra bonus, the reparse points have already been resolved!
So my question is: Is it legal to use the FileObject.FileName field in a
filter in this case? The lower FS driver already assumes the
FileObject.FileName field is the target so why shouldn’t I.
One last question: It is OK to use this on NT4.0 as well?
/ted
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com