Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Reparse points, FltGetDestinationFileName and a few other rename issues

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 450

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 :)

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online