-
Notifications
You must be signed in to change notification settings - Fork 661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DeleteFile() is never called #1082
Comments
This is the Windows design. |
I want to handle it, but the problem is that MirrorDeleteFile () is not called. |
It must be createfile called with delete on close in that case. |
I know that.. However, if you do this, the user will not receive a deletion error message. |
The user will have message if the app issuing the delete displays one. Dokany cannot do anything here. |
The current Mirror sample is implemented so that the read-only file can not be deleted. However, if you delete a read-only file from Windows Explorer, you will see just deleted without displaying any message. But when renewal, it appears again. This is not normal. |
If the user implementation allows the CreateFile that deletes the read only file to succeed, it is normal there is no error displayed since it allowed it. |
I cannot agree with what you said. Mirror sample is implemented to could not delete read-only files, and are not actually deleted. MirrorDeleteFile() <--- Never called when delete read-only file from windows explorer. and you can see below code in MirrorCreateFile().
|
It does not need. Explorer open the file with DeleteOnClose which means the file needs to be deleted during cleanup.
I am not able to reproduce this. What are the steps ? |
DeleteFile.mp4"Explorer open the file with DeleteOnClose which means the file needs to be deleted during cleanup. " |
|
Thanks for the video but I am unable to reproduce on my side. I get the same behavior on NTFS and Dokan: The file is deleted without warning even if marked read only. Explorer removes the read only attribute after doing a getfileinformation, call SetDispositionInformationFile delete and then restore the read only attribute before the file is removed.
Lines 843 to 844 in a1a557b
Lines 898 to 910 in a1a557b
It just avoid an unnecessary call when the
Why ? We check if the file is read only before trying to ask for deletion.
Then result will have the Maybe this is an issue linked to your environment where the source file actually cannot be removed by the mirror sample ? |
<-- This is not true. see attached procmon log.
<-- Invalid_parameter is returned from DokanDispatchSetInformation, is this part called? I'm just asking because I don't know.
<-- I also expected that . but on MirrorCleanup FileInfo->DeleteOnClose flag is still active even if i clear that flag on MirrorCreateFile. |
Looking at your procmon it will not be called by the system since the delete happens with DeleteOnClose.
That's not how it works. The system asks you to open a file with DeleteOnClose and you have to agree with a status_success or to refuse with access denied. From your procmon you return success so you need to issue a delete on the file during cleanup. I would suggest you read the Microsoft documentation regarding deletion. I must say that is very difficult to help you as you are providing information chunk by chunk without even logs. |
I tested it again on another VM. I don't know yet if there are any differences between the VMs, but I've confirmed that it works just like you said.
I'll have to check this out a bit more when I have time. Something is still not clear. |
Feature request can skip this form. Bug report must complete it.
Check List
must be 100% match or it will be automatically closed without further discussion. Please remove this line.Environment
Check List
Description
I found some similar issue with related this but i report.
I think all file deletion call's currently processed in cleanup() with delete_on_close. but this is not right way.
This will give the application no control over file deletion. When SetDispositionInformationFile is called with DELETE flag, DeleteFile() on the user side must be explicitly called.
Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.
The text was updated successfully, but these errors were encountered: