[Ecls-list] open :supersede and rename-file advise

[Juan Jose Garcia-Ripoll]

Hi,

I was writing an answer to this when I saw your new email with a patch.

On Nov 26, 2007 2:12 PM, Geo Carncross <geocar at gmail.com> wrote:
> Under unix, robust applications tend to write to new files in the following way: [...]
>
>   fd = open(tempfile, O_EXCL|O_CREAT, 0600);
>   ... write to fd ...
>   if (fsync(fd) == -1) goto fail;
>   if (close(fd) == -1) goto fail; /* NFS can fail here */
>   if (rename(tempfile, realfile) == -1) goto fail;
>
> This has the benefit of having no points where "realfile" has
> incomplete or invalid data.[...] in checking clhs it seems
> that (open :supersede) is allowed to have these semantics. If so,
> would you accept a patch that implements :supersede as such?

Nothing against this. I very much welcome a patch.

> If I want to generate an error if "realname" exists with still having
> that benefit, I do the rename-step as: [...]
> Under sbcl I can use sb-posix:link, rename, and unlink to simulate the
> last few steps, and under openmcl rename-file is implemented as a
> link/unlink pair (and thus generates an error) while ccl::unix-rename
> can be used to get a rename that clobbers the existing file. [...]
> I should also point out that cl:rename-file triggers an error on sbcl,
> clisp, and openmcl whenever the target file already exists. ecl
> differs in this regard.

This is a different issue, isn't it? I mean, the supersede semantics
is going to replace the original file when the new one is closed, and
rename() will then simply wipe out the old one and replace it with the
new one in an atomic fashion.

CL:RENAME-FILE does this for you and the Hyperspec does not specify
whether the rename operation has to fail on an existing file or not
http://www.lisp.org/HyperSpec/Body/fun_rename-file.html
Indeed, if it fails, I find it disturbing since it removes, not adds
functionality. With a RENAME-FILE that replaces existing files, I can
include the check if I want to avoid such operations. The operation
remains atomic. If I _always_ forbid to replace existing files then I
will have to go through serious twists (check for existing file,
delete it then, call RENAME-FILE again) and will lose atomicity.

So, please tell me whether the patch with the :supersede implements
the expected behavior:
* Write to a temporary file
* Replace old file with new one
And tell me whether there are changes in the patch file which I should
remove, namely a change in the semantics of RENAME-FILE.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com