I am positive this is a case where the documentation was written
to explain an implementation artifact. That note wasn't added
until 11 months ago ... by Mario.
The current implementation returns "foo" if a file foo
(not just a directory foo) already exists. No one is
ever going to check this return value. It seems to me
if regular file "foo" exists it should be an error.
I don't think it's atomic any more if you ignore EEXISTS, because
1) the existing directory could be owned by the wrong person
2) it might still be a regular file
3) when used to implement dotlocking, the caller needs to know
whether EEXISTS was returned, akin to using O_CREATE|O_EXCL.
Unfortunately as Peter suggested, I doubt we could change the
behavior to error out when the directory exists, because some
code probably relies on it.
I think we could error out on regular file existing, i.e. change
file-exists? to directory-exists? or perhaps check type
after the fact on EEXISTS.
But making it atomic would probably require a new procedure name,
which does not check for existence beforehand and does not
ignore EEXISTS. You could still ignore EEXISTS if creating
the full path (parents? == #t). This is then like mkdir -p.
It's how I would expect it to behave and preserves atomicity.
This could potentially go in the posix-extras egg.
Jim
signature.asc