Reparse points, FltGetDestinationFileName and a few other rename issues

This post is informational, there isn’t really a question in here, but feel free to add/comment. All the comments are for Normalized file name resolutions only.
If a reparse point is present in a Rename request, sometimes we get STATUS_INVALID_DEVICE_REQUEST/STATUS_NOT_SAME_DEVICE. I would expect it to return STATUS_NOT_SAME_DEIVCE if a rename across volumes is tested, however, this occurs even if the reparse eventually comes back to the same volume.
E.g. C:\Test\MP1 points to D:\Test
D:\Test\MP2 points to C:\Test\Folder
If a rename c:\Test\MP1\Filename.ext > C:\Test\MP1\MP2\Folder\FIleName.ext is attempted, it would result in STATUS_NOT_SAME_DEVICE. There are a few other error options, if the minifilter is not attached to the D: drive however! And these change between Windows version.
Interestingly FltGetFileNameInformation will return STATUS_NOT_SAME_DEVICE (or a similar error) if a name resolution request is made in pre-create and a reparse point points to a different volume. HOWEVER, if it points to a different volume BUT to an invalid location, it will return STATUS_OBJECT_PATH_NOT_FOUND. To some this might make sense, but it still does not make any sense to me.

Second issue. NTFS uses the destination file object during a rename/hard link creation as the file name source (you can check this by putting a data access breakpoint on the location of IrpSp->Parameters.SetFile.FileObject and on the location of the FileNameLength for the FILE_RENAME_INFORMATION structure and see which one is touched).
Now, suppose you change the open for the destination file object to point to a different file… the rename destination file name would not be valid if you took into account FILE_RENAME_INFORMATION. Actually, it is not valid for NTFS if the IrpSp->Parameters.SetFile.FileObject is not used as the destination file name.
Consider this case: The SL_OPEN_TARGET_DIRECTORY open is for the \DestFileName.ext. If you replace the file name in PreCreate to , you would get a failed rename, even if DestFileName.ext does not exist, and even if ReplaceIfExists is TRUE (you cannot rename TO an existing folder).

Just a few things to think about… I am starting to have sympathy for the folks who worked on name resolution in FltMgr :slight_smile: