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)
|
>> 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.