* CROSSPOSTED TO comp.os.ms-windows.programmer.nt.kernel-mode
Hi All,
I have some troubles with mini-filter driver I am working on, so I am
looking for help. Thanks in advance for any help and advice you guys
can provide!
The mini-filter based on the mini-filter scanner sample from the IFS Kit
(\src\filesys\minifilter\scanner). Currently, the mini-filter has four
callbacks: pre-create, post-create, pre-write, and post-cleanup. In
some cases, mini-filter needs to delete file in post-cleanup callback.
Here are my questions:
- What is the proper way to delete files on the network share in the
post-cleanup callback? - Why the IO_IGNORE_SHARE_ACCESS_CHECK flag does not have any effect on
the network share? - Is there another way to accomplish deleting file as a result of
cleanup processing?
The problem is that the mini-filter fails to delete files in scenario
with two networked computers, specifically:
- The computer “A” connected to computer “B” within the same
workgroup. - The mini-filter driver is up and running on the computer “A”.
- The computer “B” has a network share named \MACHINE_B\SHARE.
- From within Notepad.exe running on the computer “A” save a file to a
LANMAN network share \MACHINE_B\SHARE located on the computer “B”. - During saving the file the mini-filter decides to delete newly
created file on the computer “B” in its post-cleanup callback (to delete
a file the mini-filter uses standard calling sequence: open file -> set
file information with FileDispositionInformation class -> close file). - At the post-cleanup callback the newly created file is already
closed, so in order to delete this file the mini-filter needs to open it
first. However, for some reason the operating system does not open the
file and returns STATUS_SHARING_VIOLATION in the case if the DELETE (or
GENERIC_WRITE) bit is set in the DesiredAccess parameter.
I have tried the following documented functions/flags to open the file
on the network share with DELETE bit in DesiredAccess parameter:
- FltCreateFile passing correct Instance parameter and
IO_IGNORE_SHARE_ACCESS_CHECK flag. - IoCreateFileSpecifyDeviceObjectHint with IO_IGNORE_SHARE_ACCESS_CHECK
(reentrancy protected); - Plain ZwCreateFile (reentrancy protected);
None of these functions did succeed in the opening file for deletion on
the network share located on the computer “B”. The very same functions
do work properly on any of the local file systems on the computer “A”.
Below is some additional information:
The sequence of File I/O operations coming from Notepad.exe as the
mini-filter sees it:
- IRP_MJ_CREATE (mini-filter receives it as pre- and post-callbacks).
- IRP_MJ_WRITE (pre-callback).
- Second IRP_MJ_CREATE (pre-callback). This time mini-filter decides
to delete file, and OS returns STATUS_SHARING_VIOLATION. Thus,
mini-filter sets file operation status to STATUS_ACCESS_DENIED (using
IoStatus field of the passed in FLT_CALLBACK_DATA structure). - System works for a couple of milliseconds and I see some unrelated
open operations for different files. - IRP_MJ_CLEANUP (post-callback). Again, mini-filter tries to delete
file, but OS returns STATUS_SHARING_VIOLATION.
As it should be, the system passes the same file object for operations
1,2 and 5, and different for operation 3.
Observed behavior does not depend on the target file system type on the
computer “B”. I have tried to share both FAT and NTFS folders on the
computer “B” and behavior is still the same. I also used FILEMON on the
computer “B” to monitor File I/O activity locally on the computer “B”.
The file system on the computer “B” does not return
STATUS_SHARING_VIOLATION during testing. So it seems to be a
STATUS_SHARING_VIOLATION problem on the computer “A” only (remember, the
mini-filter executes on the computer “A”, but the actual file that
mini-filter tries to open located on the LANMAN network share
\MACHINE_B\SHARE on the computer “B”).
I tried to use work items to delete files and it does not work either.
This is because system thread, which executes work items, has different
access token in comparison to the Notepad.exe thread that saves the
file. This different token does not allow access to the target computer
“B” at the time work item is executed.
Again, thanks in advance for any help and advice!