[Carlbyte]

Would be possible to cancel an operation to delete a file, but return to the program that called deletefile () a response that the operation completed successfully? If not, in which PFLT_CALLBACK_DATA property do I get the path to the file being deleted?

thanks

[tangptr]

Hello, Carlbyte!

I'm so sorry that I'm not able to answer your question accurately, for there are some syntactic errors which may interfere with my understanding.
It seemed that you are going to ask about a question that whether there is a sort of possibility that while cancelling deletion, the function returns success in response to the caller.
About this question, I don't know if it would safe or not. If it were safe, you could return success.
In response to your second question, you may call function "FltGetFileNameInformation" in order to get the information about the file name. If confused with the usage, you may search its usage in the MSDN. I think that you might confused with the usage in MiniFilter. Am I right?

[Carlbyte]

Imagine that a program call deletefile(x.txt) and in my driver I want to make a copy of the file and then delete the file "x.txt".
...
The purpose of questioning in which property of the FLT_CALLBACK_DATA pointer I find the path to the file, is to try a status_reparse

[Vrtule]

Imagine that a program call deletefile(x.txt) and in my driver I want to make a copy of the file and then delete the file "x.txt".

Setting the IoStatus member of the FLT_CALLBACK_DATA structure to success and returning FLT_PREOP_COMPLETE from your IRP_MJ_SET_INFORMATION minifilter callback returns control to the program calling DeleteFile by saying "operation completed successfully" (well, this is imprecise, since the callback is triggered on behalf of NtSetInformationFile but that probably does not matter in your case).

The purpose of questioning in which property of the FLT_CALLBACK_DATA pointer I find the path to the file, is to try a status_reparse

You may use FltGetFileNameInformation to obtain the file name (including the full path). All you need is provided to your minifilter callback. But keep in mind, that the routine may actually send a query-name request to the target file (this probably is not a problem in your case but may be unpleasant in some others).

[N3mes1s]

fyi:

- https://github.com/Microsoft/Windows-dr ... ter/delete

The Delete minifilter is an example that demonstrates how to detect deletions of files or streams. Deletions are reported as debug output.

[Carlbyte]

Returning status success and FLT_PREOP_COMPLETE is enough for what I wanted. The problem is occurring when I try to detect the delete event made by explorer.exe, it handles the issue in a different way. I could not detect until now, if it does with a delete_on_close ... Anyone with any tips?

[Vrtule]

Hello,

Look for IRP_MJ_CREATE with delete on close in attributes.

I am not sure whether setting success and returning FLT_PREOP_COMPLETE would do the job. But you may try.

[Carlbyte]

I've already verified that explorer calls 2 times the deletefile and then renames the file to recycle bin. But I had a question with this delete_on_close flag. When the system deletes a file using this "delete_on_close" flag procedure, does the system call irp_mj_set_information with filedispositioninformation?

[Vrtule]

No, it does not. Opening and closing the file is enough.