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:01 UTC

> Hi, I'm pretty late on the discussion, but I just started implementing
> srfi-170 to Gauche
> to see how it works.

Nice!

> One thing I couldn't find in the discussion archive is the rationale of
> override? optional
> argument in create-{directory|fifo|hard-link|symlink}.  It's not in
> underlying POSIX call.
> Supposedly it's for convenience, but I don't think it can reliably be
> used (suppose two
> process trying to create objects with the same name simultaneously), and
> I feel better to leave it to the upper layer to handle various
> application-specific
> requirements.

(ensure-directory-exists "foo" [permission-bits]) would be very useful.
This would be a subset of the behavior of create-directory's current
override flag.

I agree about the other cases. In particular, deleting an existing file
system object of whatever type happens to be there) and replacing it
with another object of a particular type sounds quite hazardous. When
replacing an object with the _same_ type of object, it is more likely
that the programmer knows what they are doing.