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