I am using the following instruction to capture DELETE operation, it works on
XP, Vista, Win7, Win2003, Win2008 x86/x64 but failed on Win8 x86/x64.
#define IS_DELETE_OPERATION(Data) ( \
Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION && \
Data->Iopb->Parameters.SetFileInformation.FileInformationClass == \
FileDispositionInformation && \
( ( PFILE_DISPOSITION_INFORMATION) \
Data->Iopb->Parameters.SetFileInformation.InfoBuffer)->DeleteFile )
Please advise.
Check the archive. This is not sufficient.
All that Win8 needs to do is to reply on destructive renames or delete on
close (although that seems unlikely) and this would stop working…
WIN8 has a delete sample.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Monday, June 04, 2012 10:17 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Cannot capture DELETE operation in Windows 8 Release
Preview
Check the archive. This is not sufficient.
All that Win8 needs to do is to reply on destructive renames or delete on
close (although that seems unlikely) and this would stop working…
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
On 06/04/2012 07:17 AM, Rod Widdowson wrote:
All that Win8 needs to do is to reply on destructive renames or delete
on close (although that seems unlikely) and this would stop working…
Win8 did switch to delete on close to avoid the extra network round trip
of opening handle first, then setting delete disposition. I mention
this because I don’t think the OP will be the only one affected by this
change, even though the code given was clearly incomplete.
Just want to underline what Malcolm said. In Windows 8 deletes from cmd (i.e. “del foo”) and deletes from the Explorer shell now open the file with FILE_FLAG_DELETE_ON_CLOSE and then close the handle.
Filters should expect to see way more opens for DELETE_ON_CLOSE in Windows 8, although they should have been handling them all along.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
Christian Allred, yes the DELETE operation failed to be captured under command prompt but not
from explorer shell. Are u saying, Win8 now always with FILE_FLAG_DELETE_ON_CLOSE when
deleting a file either from command prompt or explorer ?
Please advise.
…I noticed when deleting a file via command prompt under Win8 RP,
its PostCreate() routine always with the followings elements set to TRUE:
FltObjects->FileObject->DeleteAccess
FltObjects->FileObject->SharedDelete
This however, if I denied the operation, the file already being deleted.
I try capture via PreCreate() and PreSetInfo() routine, it does not consists
any significant flags indication such as PostCreate()'s DeleteAcess and SharedDelete
above.
Therefore, is hard to capture.
Any idea is greatly appreciated.
Christian Allred, I don’t see the following statement is TRUE always, either in
PreSetInfo(), PreCreate(), PostCreate() under Win8 RP:
FltObjects->FileObject->Flags & FO_DELETE_ON_CLOSE
Please advise.
> Christian Allred, I don’t see the following statement is TRUE always, either in
?PreSetInfo(), PreCreate(), PostCreate() under Win8 RP:
> FltObjects->FileObject->Flags & FO_DELETE_ON_CLOSE?
In your PreCreate() you should look for the FILE_DELETE_ON_CLOSE flag being present in CreateOptions.?
The CreateOptions is stored as the low 24 bits of CallbackData->Iopb->Parameters.Create.Options.
> FltObjects->FileObject->Flags & FO_DELETE_ON_CLOSE
Like Razvan said you need FILE_DELETE_ON_CLOSE, this has nothing to do with
FO_DELETE_ON_CLOSE.
In general it is very unwise to make any assumptions about anything in the
File Object which is not documented. It isn’t your structure and you have
no idea how the various filesystems will use it (if at all)
from http://fsfilters.blogspot.co.uk/2012/05/using-filemodeinformation.html
"This is the only time I’ve actually seen FO_DELETE_ON_CLOSE used
anywhere. "
Note that under certain circumstances FILE_DELETE_ON_CLOSE can be undone,
just like FILE_DISPOSITION_INFORMATION can be. Consult the archives this
has been discussed to death. Or read FAT. Best of all consult the delete
example that Bill referred to. If it is the one discussed two plugfests ago
it is pretty complete.
“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
> Best of all consult the delete example that Bill referred to. If it is
> the one discussed two plugfests ago it is pretty complete.
If all that is required is a list of files that are being deleted then that
sample is sufficient. It does however not address the real challenges faced
when developing an undelete filter such as sending information down the
stack then when it’s still possible and the ability to handle subsequent
SetInformation requests which may enable or disable the delete operation
when the file object is closed.
//Daniel
Razvan Hobeanu, Christian Allred, FILE_DELETE_ON_CLOSE
on CallbackData->Iopb->Parameters.Create.Options is working
now under PreCreate().
Daniel Terhell, is true that when I denied the delete result under
PreCreate() the first time, PreSetInfo() now appeared then
PreCreate() again, followed by PreSetInfO().
How to cancel a file deletion once, without PreCreate() and
PreSetInfo() being raised up the second time ?
Here is the sample I used to deny file deletion under PreCreate():
if( !bSafeToOpen )
{
if( !FlagOn( Data->Iopb->IrpFlags, IRP_PAGING_IO ) )
{
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;
}
return FLT_PREOP_COMPLETE;
}
Not sure if I understand you correctly. But what you are seeing is probably
just an application behavior pattern, that your filter needs to be able to
deal with.If you deny the create, no file object is created so you will not
see any subsequent operations. If a new create comes by that is just
application retry behavior.
//Daniel
wrote in message news:xxxxx@ntfsd…
> Razvan Hobeanu, Christian Allred, FILE_DELETE_ON_CLOSE
> on CallbackData->Iopb->Parameters.Create.Options is working
> now under PreCreate().
>
> Daniel Terhell, is true that when I denied the delete result under
> PreCreate() the first time, PreSetInfo() now appeared then
> PreCreate() again, followed by PreSetInfO().
>
> How to cancel a file deletion once, without PreCreate() and
> PreSetInfo() being raised up the second time ?
>
> Here is the sample I used to deny file deletion under PreCreate():
>
> if( !bSafeToOpen )
> {
> if( !FlagOn( Data->Iopb->IrpFlags, IRP_PAGING_IO ) )
> {
> Data->IoStatus.Status = STATUS_ACCESS_DENIED;
> Data->IoStatus.Information = 0;
> }
> return FLT_PREOP_COMPLETE;
> }
>
>
Daniel Terhell, actually I am deleting a file via command prompt.
eg: C:\>del TEST.TXT
I did came across application behavior when write operation is denied.
eg. Notepad.exe redirected to other saving path, IE redirected to
other download pathname.
if instruction replaced FLT_PREOP_COMLETE, it will not call PreSetInfo()
but TEST.TXT is deleted although DELETE operation is denied.
return FLT_PREOP_SUCCESS_WITH_CALLBACK;
Any idea ?
You are probably doing something wrong. Put a file monitor on this so you
can get a complete list of IRPs, then you can see exactly what is going on
and how the file is deleted.
//Daniel
wrote in message news:xxxxx@ntfsd…
> Daniel Terhell, actually I am deleting a file via command prompt.
>
> eg: C:>del TEST.TXT
>
> I did came across application behavior when write operation is denied.
> eg. Notepad.exe redirected to other saving path, IE redirected to
> other download pathname.
>
> if instruction replaced FLT_PREOP_COMLETE, it will not call PreSetInfo()
> but TEST.TXT is deleted although DELETE operation is denied.
>
> return FLT_PREOP_SUCCESS_WITH_CALLBACK;
>
> Any idea ?
>
>
>
Daniel, what software to use to watch the IRP ?
Zezula’s FileSpy
//Daniel
wrote in message news:xxxxx@ntfsd…
> Daniel, what software to use to watch the IRP ?
>
Daniel, I did captured using ProcMon of deleting a file test5.txt via command prompt
but I still don’t understand why PreCreate()+PreSetInfo() are called twice, in fact it
should immediately stopped after PreCreate() the first time.
Here are the log info captured:
QueryOpen C:\Demo\test5.txt FAST IO DISALLOWED
CreateFile C:\Demo\test5.txt SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
QueryBasicInformationFile C:\Demo\test5.txt SUCCESS CreationTime: 6/8/2012 9:07:38 AM, LastAccessTime: 6/8/2012 9:07:38 AM, LastWriteTime: 3/20/2012 12:16:50 AM, ChangeTime: 6/5/2012 9:02:15 PM, FileAttributes: A
CloseFile C:\Demo\test5.txt SUCCESS
IRP_MJ_CLOSE C:\Demo\test5.txt SUCCESS
QueryOpen C:\Demo\test5.txt FAST IO DISALLOWED
CreateFile C:\Demo\test5.txt SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
QueryBasicInformationFile C:\Demo\test5.txt SUCCESS CreationTime: 6/8/2012 9:07:38 AM, LastAccessTime: 6/8/2012 9:07:38 AM, LastWriteTime: 3/20/2012 12:16:50 AM, ChangeTime: 6/5/2012 9:02:15 PM, FileAttributes: A
CloseFile C:\Demo\test5.txt SUCCESS
IRP_MJ_CLOSE C:\Demo\test5.txt SUCCESS
QueryDirectory C:\Demo\test5.txt SUCCESS Filter: test5.txt, 1: test5.txt
CreateFile C:\Demo\test5.txt ACCESS DENIED Desired Access: Delete, Disposition: Open, Options: Non-Directory File, Delete On Close, Attributes: n/a, ShareMode: Delete, AllocationSize: n/a
CreateFile C:\Demo\test5.txt SUCCESS Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
QueryAttributeTagFile C:\Demo\test5.txt SUCCESS Attributes: A, ReparseTag: 0x0
SetDispositionInformationFile C:\Demo\test5.txt ACCESS DENIED Delete: True
CloseFile C:\Demo\test5.txt SUCCESS
IRP_MJ_CLOSE C:\Demo\test5.txt SUCCESS
CreateFile C:\Demo\test5.txt ACCESS DENIED Desired Access: Delete, Disposition: Open, Options: Non-Directory File, Delete On Close, Attributes: n/a, ShareMode: Delete, AllocationSize: n/a
CreateFile C:\Demo\test5.txt SUCCESS Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
QueryAttributeTagFile C:\Demo\test5.txt SUCCESS Attributes: A, ReparseTag: 0x0
SetDispositionInformationFile C:\Demo\test5.txt ACCESS DENIED Delete: True
CloseFile C:\Demo\test5.txt SUCCESS
Any help will be appreciated :o)
What makes you think it should have stopped immediately ? This is
application behavior, that you have to live with.
//Daniel
wrote in message news:xxxxx@ntfsd…
> Daniel, I did captured using ProcMon of deleting a file test5.txt via
> command prompt
> but I still don’t understand why PreCreate()+PreSetInfo() are called
> twice, in fact it
> should immediately stopped after PreCreate() the first time.
>
…if I return with FLT_PREOP_SUCCESS_WITH_NO_CALLBACK, it delete the file even
it is denied, and no PreSetInfo() is called or repeat PreCreate()+PreSetInfo() the second
time. Therefore, I just wonder is there an option to do so.