[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-11-03 19:00:09 CET

"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
Received on Mon Nov 3 19:01:09 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.