-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
Zig Version
0.10.0-dev.4247+3234e8de3
Steps to Reproduce
The std.fs permissions tests take special steps to undo the read-only flag before allowing the tmp_dir to be cleaned up because otherwise the file (and tmp dir) would fail to get cleaned up (due to CANNOT_DELETE returned from DeleteFile):
Lines 1243 to 1245 in 3234e8d
| // Must be set to non-read-only to delete | |
| permissions.setReadOnly(false); | |
| try file.setPermissions(permissions); |
This is required; from https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-deletefile:
To delete a read-only file, first you must remove the read-only attribute.
CANNOT_DELETE being translated to error.AccessDenied was done by me in #10495 but I'm second guessing whether or not this is the correct way to go, as it means that deleteFile will fail for read-only files and deleteTree will fail for any tree with a read-only file inside it, the latter of which is probably unexpected behavior.
An alternate implementation could be to try to recover from CANNOT_DELETE by trying to unset the read-only flag and then retrying the delete. Where exactly this handling of deletion of read-only files should be handled I'm unsure about (at the deleteFile level, or only for deleteTree?).
Expected Behavior
deleteTree and possibily deleteFile successfully delete read-only files on Windows
Actual Behavior
deleteFile fails on read-only files with error.AccessDenied, and in turn deleteTree fails and returns error.AccessDenied whenever it hits a read-only file.