Re: svn rev 7611: FAIL (i386-unknown-freebsdelf5.0 static ra_local)

"Sander Striker" <striker@apache.org> writes:

> Index: file_io/unix/open.c
> ===================================================================
> RCS file: /home/cvs/apr/file_io/unix/open.c,v
> retrieving revision 1.111
> diff -u -r1.111 open.c
> --- file_io/unix/open.c 19 Mar 2003 03:45:42 -0000 1.111
> +++ file_io/unix/open.c 3 Nov 2003 12:18:47 -0000
> @@ -216,7 +216,17 @@
> const char *to_path,
> apr_pool_t *p)
> {
> + apr_status_t rv;
> +
> if (rename(from_path, to_path) != 0) {
> + if (errno == EXDEV) {
> + rv = apr_file_copy(from_path, to_path, APR_FILE_SOURCE_PERMS, p);
> + if (rv)
> + return rv;
> +
> + return apr_file_remove(from_path, p);
> + }
> +
> return errno;
> }
> return APR_SUCCESS;

The problem with a copy and delete implementation is that the copy can
fail (or be interrupted) part way through, in which case the original
destination file may be lost. A traditional Unix rename guarantees
that the destination is either unmodified or replaced.

Perhaps the copy should be made to a temporary file in the destination
directory, then once the copy is complete the temporary file could be
renamed, followed by deletion of the temporary or source as
appropriate.

Subversion relies on the atomic nature of renames, although I note
that the APR documentation doesn't provide any such guarantee
directly. On Unix, at least, it is implied by the warning about
crossing devices.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org