override? argument in create-directory etc. Shiro Kawai (22 Apr 2020 20:57 UTC)
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 21:01 UTC)
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 21:06 UTC)
Re: override? argument in create-directory etc. Shiro Kawai (22 Apr 2020 21:13 UTC)
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 21:28 UTC)
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 21:48 UTC)
Re: override? argument in create-directory etc. John Cowan (22 Apr 2020 23:05 UTC)
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 23:13 UTC)
(missing)
(missing)
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 23:36 UTC)
Re: override? argument in create-directory etc. Shiro Kawai (22 Apr 2020 23:59 UTC)

Re: override? argument in create-directory etc. Lassi Kortela 22 Apr 2020 21:48 UTC

>> If we want ensure-* functionality, which seems to be more useful in
>> practice, I'd suggest the optional argument
>> to be a flag of "if the desired type of filesystem object
>> already exists, then just change the mode and return".

For create-hard-link and create-symlink, it's important that the link
ends up pointing to the filename given by the caller. Hence even if the
right kind of link existed before, it should be ensured to point to the
new filename.

I'm not sure whether or not the mode of existing objects should be changed.

In general, it would seem safest to avoid these unusual kinds of APIs
unless there is a strong rationale.