STATUS_REPARSE to shadow file

NTFSD
1

Hello,

I’m writing a minifilter to redirect new files and changes to existing files
that reside on volumes on certain bus types (e.g., USB or 1394) to shadow
files on another volume (e.g., to a temp directory on the boot volume). The
intention being to restore those shadow files to their original destinations
at a later time. The redirection is being done by changing
TargetFileObject->FileName, setting STATUS_REPARSE/IO_REPARSE, and returning
FLT_PREOP_COMPLETE within the IRP_MJ_CREATE callback. This is very similar
to the redirection used in the article “How to Get There from Here –
Redirecting Create Requests”
(http://www.osronline.com/article.cfm?article=397). It works as expected
and all is well for most of the applications that I’ve tested.

However, something is not quite right because I cannot get some Office 2007
apps to play nice - and I fully expect to find more apps with problems. For
example, if an existing Word document is opened from a targeted volume and
changes are made, when the file is saved, Word displays the following error:
“Word cannot complete the save due to a file permission error.”

I can see that the .docx file is redirected; that’s good. I can also see
that the temp files that Word creates during the save are redirected; that’s
good. However, there is an IRP_MJ_CREATE which fails with
STATUS_PRIVILEGE_NOT_HELD after attempting to open a temp file with desired
access 0x1130089 (FILE_GENERIC_READ | DELETE | ACCESS_SYSTEM_SECURITY);
that’s bad. ACCESS_SYSTEM_SECURITY requires SeSecurityPrivilege, and sure
enough, that privilege is missing. I’ve verified with minispy that no such
create is issued with that desired access if my driver is not running, so
it’s obviously a problem that I’m creating somewhere before this create, but
I’ve not been able track it down.

Is this an issue that anyone else has encountered? Any ideas otherwise? Am
I wrong to assume that redirecting IRP_MJ_CREATE with
STATUS_REPARSE/IO_REPARSE is enough to ensure that all file creates and
modifications will be redirected from the target volume to my shadow
location?

Thank you,
Jason

2

> I’ve verified with minispy that no such create is issued with that desired

access if my driver is not running, so it’s obviously a problem that I’m
creating somewhere before this create, but I’ve not been able track it
down.

As Rod might say, “spiteful”

I’m afraid I can’t be of much help, but what I can say is that in the DMK we
do heavily use STATUS_REPARSE and I have not seen this issue (I’ve seen a
lot of Office issues on a lot of different versions, but not this one). You
could also prove to yourself that it’s not fundamentally broken by using a
mount point. Tracing the activity in that situation and matching it up with
yours might also lead to some clues.

Unfortunately, Office is the application that I always mention when talking
about horrible problems to track down. Crashes are one thing, but “Office
throws an error dialog” is something else. Whenever I have these I usually
start with isolating the create and working backwards. Hopefully you won’t
need to go far to find the point where the paths fork.

Good luck and I shall keep you in my prayers…

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Looking forward to seeing you at the next OSR Kernel Debugging Class April
6, 2009 in Portland, OR!

“Jason F.” wrote in message news:xxxxx@ntfsd…
> Hello,
>
> I’m writing a minifilter to redirect new files and changes to existing
> files that reside on volumes on certain bus types (e.g., USB or 1394) to
> shadow files on another volume (e.g., to a temp directory on the boot
> volume). The intention being to restore those shadow files to their
> original destinations at a later time. The redirection is being done by
> changing TargetFileObject->FileName, setting STATUS_REPARSE/IO_REPARSE,
> and returning FLT_PREOP_COMPLETE within the IRP_MJ_CREATE callback. This
> is very similar to the redirection used in the article “How to Get There
> from Here – Redirecting Create Requests”
> (http://www.osronline.com/article.cfm?article=397). It works as expected
> and all is well for most of the applications that I’ve tested.
>
> However, something is not quite right because I cannot get some Office
> 2007 apps to play nice - and I fully expect to find more apps with
> problems. For example, if an existing Word document is opened from a
> targeted volume and changes are made, when the file is saved, Word
> displays the following error: “Word cannot complete the save due to a file
> permission error.”
>
> I can see that the .docx file is redirected; that’s good. I can also see
> that the temp files that Word creates during the save are redirected;
> that’s good. However, there is an IRP_MJ_CREATE which fails with
> STATUS_PRIVILEGE_NOT_HELD after attempting to open a temp file with
> desired access 0x1130089 (FILE_GENERIC_READ | DELETE |
> ACCESS_SYSTEM_SECURITY); that’s bad. ACCESS_SYSTEM_SECURITY requires
> SeSecurityPrivilege, and sure enough, that privilege is missing. I’ve
> verified with minispy that no such create is issued with that desired
> access if my driver is not running, so it’s obviously a problem that I’m
> creating somewhere before this create, but I’ve not been able track it
> down.
>
> Is this an issue that anyone else has encountered? Any ideas otherwise?
> Am I wrong to assume that redirecting IRP_MJ_CREATE with
> STATUS_REPARSE/IO_REPARSE is enough to ensure that all file creates and
> modifications will be redirected from the target volume to my shadow
> location?
>
> Thank you,
> Jason
>

3

Take a look at the new simulate reparse minifilter sample in the WDK7. It
shows how to replace file names in file objects at pre-create either by
using IoReplaceFileObjectName or by manually overwriting it.

One of the things it does is disallowing fast I/O because it does not
support STATUS_REPARSE. The problem with manually overwriting the filename
in the fileobject is that you cannot manage the lifetime of the buffer and
you will leak pool.

//Daniel

“Jason F.” wrote in message news:xxxxx@ntfsd…
> Hello,
>
> I’m writing a minifilter to redirect new files and changes to existing
> files that reside on volumes on certain bus types (e.g., USB or 1394) to
> shadow files on another volume (e.g., to a temp directory on the boot
> volume). The intention being to restore those shadow files to their
> original destinations at a later time. The redirection is being done by
> changing TargetFileObject->FileName, setting STATUS_REPARSE/IO_REPARSE,
> and returning FLT_PREOP_COMPLETE within the IRP_MJ_CREATE callback. This
> is very similar to the redirection used in the article “How to Get There
> from Here – Redirecting Create Requests”
> (http://www.osronline.com/article.cfm?article=397). It works as expected
> and all is well for most of the applications that I’ve tested.
>
> However, something is not quite right because I cannot get some Office
> 2007 apps to play nice - and I fully expect to find more apps with
> problems. For example, if an existing Word document is opened from a
> targeted volume and changes are made, when the file is saved, Word
> displays the following error: “Word cannot complete the save due to a file
> permission error.”
>
> I can see that the .docx file is redirected; that’s good. I can also see
> that the temp files that Word creates during the save are redirected;
> that’s good. However, there is an IRP_MJ_CREATE which fails with
> STATUS_PRIVILEGE_NOT_HELD after attempting to open a temp file with
> desired access 0x1130089 (FILE_GENERIC_READ | DELETE |
> ACCESS_SYSTEM_SECURITY); that’s bad. ACCESS_SYSTEM_SECURITY requires
> SeSecurityPrivilege, and sure enough, that privilege is missing. I’ve
> verified with minispy that no such create is issued with that desired
> access if my driver is not running, so it’s obviously a problem that I’m
> creating somewhere before this create, but I’ve not been able track it
> down.
>
> Is this an issue that anyone else has encountered? Any ideas otherwise?
> Am I wrong to assume that redirecting IRP_MJ_CREATE with
> STATUS_REPARSE/IO_REPARSE is enough to ensure that all file creates and
> modifications will be redirected from the target volume to my shadow
> location?
>
> Thank you,
> Jason
>

4

Jason,

You may have a design problem in your filter to handle rename. The save from xyz.tmp to xyz.docx is actually a rename. when IoMgr handles this rename, it knows where the rename source xyz.tmp was actually opened (e.g. C:), it then needs to open the parent directory of the target name xyz.docx. If you let this open of the parent directory go through to its native location (in your case, the USB drive), then IoMgr will see the source name and the target directory within two different volumes. This will fail the rename. About STATUS_PRIVILEGE_NOT_HELD with ACCESS_SYSTEM_SECURITY desired access, you may safely ignore it, it is a side effect from the user mode replace file api.

Hui

5

>IoMgr will see the source name and the target directory within two different volumes. This will fail the

rename.

Exactly so. Cross-volume rename/moves are caught in IoMgr itself, and filter cannot help with this - it will not see them at all.

In one our old product, we used the hooker DLLs loaded by AppInit_DLLs to hook MoveFile for this and replace it with a copy.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Thanks everyone for the feedback.

Hui, I had thought the rename might be part of the problem, but I was able
to perform renames within explorer and at the cmd prompt without any issues.
However, I hadn’t considered ReplaceFile. I created a simple test app that
calls ReplaceFile with both the replaced and replacement files on a volume
that I am targeting, and it fails with ERROR_UNABLE_TO_REMOVE_REPLACED. It
also reproduced the STATUS_PRIVILEGE_NOT_HELD failure that I had originally
posted about (and that you mentioned in your reply). Being able to
reproduce the problem outside of Word is a great help.

The problem being with the parent directory makes some sense. I had been
purposely skipping directories when determining if a redirect should be
made. So I modified my driver to redirect all create operations, including
those on directories. For example, IRP_MJ_CREATE for
\Device\HarddiskVolume2\ is redirected to \Device\HarddiskVolume1\Temp.
I’m skipping volume opens. I had assumed this would catch the open of the
parent directory of the docx file (which it appears to) and prevent the
rename from appearing to be on two different volumes. However, the save
still fails with the same conditions (my ReplaceFile test app also still
fails). There must be some aspect of the rename that I’m not grasping. Can
you offer any other clues as to what I’m missing?

Thank you,
Jason

wrote in message news:xxxxx@ntfsd…
> Jason,
>
> You may have a design problem in your filter to handle rename. The save
> from xyz.tmp to xyz.docx is actually a rename. when IoMgr handles this
> rename, it knows where the rename source xyz.tmp was actually opened (e.g.
> C:), it then needs to open the parent directory of the target name
> xyz.docx. If you let this open of the parent directory go through to its
> native location (in your case, the USB drive), then IoMgr will see the
> source name and the target directory within two different volumes. This
> will fail the rename. About STATUS_PRIVILEGE_NOT_HELD with
> ACCESS_SYSTEM_SECURITY desired access, you may safely ignore it, it is a
> side effect from the user mode replace file api.
>
> Hui
>

7

Jason,

You may need to implement PreSetInfo callback to handle rename as well. Since you have reparsed everything from the USB to c:\temp (assume c:\temp has the directory tree as the USB volume), iomgr will let your filter see the rename operation. If you look at the target name buffer, typically it is either a relative name or a full path. You don’t have to worry about the relative name. The full path name is typically in the format of ??\U:\dir1\file2 (assume U: is the USB volume), which is, I suspect the case that is broken. You have to either swap the buffer to the C: name, or roll your own FltSetInformation with the C: name. Note if you call FltGetDestinationFileNameInfo to get the target name in the PreSetInfo callback, it might fail because your filter is not a name provider filter, so you may have to parse the target name buffer by yourself.

This way, you may workaround the rename issue, but it is still not a complete solution. I have not found a universal solution to handle rename with reparse. But it might be okay in your particular use case.

Hui
This posting is provided as is with no warranties, and confers no rights.