Skip to content
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

removeDirectoryRecursive: permission denied (Access is denied.) Windows #59

Closed
wapxmas opened this issue Aug 2, 2016 · 5 comments

Comments

@wapxmas
Copy link

commented Aug 2, 2016

Please read this issue. Thanks.

@Blaisorblade

This comment has been minimized.

Copy link

commented Aug 2, 2016

Thanks for your investigation on the original issue (got here from stack)!

To summarize (correct me if I'm wrong): removeFile hence removeDirectoryRecursive can't remove read-only files, even when it is possible by first clearing the read-only flag. Do you propose indeed clearing the read-only flag? That would certainly be consistent with the behavior on Unix.

https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa363915(v=vs.85).aspx

@wapxmas

This comment has been minimized.

Copy link
Author

commented Aug 2, 2016

Yes, I think that clearing read-only flag when it is possible it is right behavior. I think if I need to delete file or directory recursive I don`t really care read-only file or not. Thanks.

@Rufflewind

This comment has been minimized.

Copy link
Member

commented Aug 3, 2016

That would certainly be consistent with the behavior on Unix.

*nix and Windows behave differently in that on *nix the permission to delete is determined by the write-bit on the parent directory, whereas on Windows the permission to delete is determined by the attributes of the file itself. I don't believe there's a way to make this "consistent" without doing a lot of ugly hacks.


I agree that the failure to delete read-only files is kind of annoying and probably not what the user expects.

However, I'm somewhat hesitant on changing the behavior of a core function such as removeFile. Moreover, it is currently consistent with the behavior in Python's standard library.

I could add something like removeFileForcibly though, or maybe a helper function like setWritablePermission :: Bool -> FilePath -> IO ().

@Blaisorblade

This comment has been minimized.

Copy link

commented Aug 3, 2016

I agree a bit with your hesitation; I'd propose to add mention of this issue then for removeFile together with any addition.

Would you be open to changing removeDirectoryRecursive to use removeFileForcibly though, or adding a variant for that?
For the original linked issue on Stack, I think we would want a portable rm -rf which does remove readonly files.

I suppose that at least any build tool removing directories it created (cabal-install, Shake, ...) would need the same behavior, so I think this would be useful in a common package rather than inside Stack.

Since you mention the Python standard library, I found its shutil.rmtree function: they provide a callback for handling errors on a single deletion, which could be used to change permissions and allow to resume operations.

Rufflewind added a commit to Rufflewind/directory that referenced this issue Aug 4, 2016

@Rufflewind Rufflewind added this to the 1.2.7.0 milestone Aug 4, 2016

@Rufflewind Rufflewind self-assigned this Aug 4, 2016

@Rufflewind

This comment has been minimized.

Copy link
Member

commented Aug 4, 2016

I've added removePathForcibly, which can remove files or directories even if they are read-only or non-existent.

@Rufflewind Rufflewind closed this in 7f40ee3 Aug 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.