I'll adjust the docs to clarify that the permission change followed by
delete is a non-atomic sequence, with no attempt to revert a permission
change if the delete fails.
Ending up with just the permission change is one possible outcome, and
I hope the clarification will also make other outcomes more apparent.
For example, it could happen that X's permission is changed, then X is
concurrently replaced by a new file again without write permission, and
the still-in-progress delete fails due to a permission failure after
all.
At Wed, 14 Jan 2015 09:31:37 -0600, Robby Findler wrote:
Is it perhaps worth being more explicit about this possibility in the
docs? I'm thinking of a sentence that says when the parameter is
set, delete-file may have only the effect of changing the permissions
on the file or similar.
Robby
On Wed, Jan 14, 2015 at 8:29 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote:
On 01/13/2015 02:00 PM, mfl...@racket-lang.org wrote:
9f3c82c Matthew Flatt mfl...@racket-lang.org 2015-01-13 08:47
:
| Windows: change `delete-{file,directory}` to attempt permission
correction
|
| If a file or directory delete fails, try adjusting the file or
directory
| permissions to allow writes, then try deleting again. This process
should
| provide a more Unix-like experience and make programs behave more
| consistently.
|
| A new `current-force-delete-permissions` parameter provides access to
| the raw native behavior.
If I'm understand the new behavior correctly, it's possible for a
failing `delete-file` to raise an exception, having changed the file to
be writable. Do I have that right, and is that OK?
That is correct. I'm not too happy about it, but I think it's a good
trade-off relative to the old behavior (as a default).
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
