Re: [racket-dev] [plt] Push #29680: master branch updated
I like that. Thanks, Robby On Wed, Jan 14, 2015 at 2:29 PM, Matthew Flatt wrote: > 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 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 wrote: >> > At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote: >> >> On 01/13/2015 02:00 PM, [email protected] wrote: >> >> > 9f3c82c Matthew Flatt 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
Re: [racket-dev] [plt] Push #29680: master branch updated
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 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 wrote: > > At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote: > >> On 01/13/2015 02:00 PM, [email protected] wrote: > >> > 9f3c82c Matthew Flatt 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
Re: [racket-dev] [plt] Push #29680: master branch updated
Is it perhaps worth being more explicit about this possibility in the docs? I'm thinking of a sentence that says "when 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 wrote: > At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote: >> On 01/13/2015 02:00 PM, [email protected] wrote: >> > 9f3c82c Matthew Flatt 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
Re: [racket-dev] [plt] Push #29680: master branch updated
At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote: > On 01/13/2015 02:00 PM, [email protected] wrote: > > 9f3c82c Matthew Flatt 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
Re: [racket-dev] [plt] Push #29680: master branch updated
On 01/13/2015 02:00 PM, [email protected] wrote: 9f3c82c Matthew Flatt 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? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
