[patch] add Transport.rename

[Martin Pool]

On Tue, 2006-02-14 at 09:08 -0600, John A Meinel wrote:

> Robey Pointer wrote:
> > On 13 Feb 2006, at 14:54, Robert Collins wrote:
> > 
> >> I think we have a slightly confusing transport api, which this branch
> >> has shown up...
> >>
> >> fancy_rename is more of a fancy_replace function IMO, and its use by
> >> windows and sftp to implement 'semi atomic renames that replace' is
> >> misleading.
> >>
> >> So I propose that we
> >>  * rename fancy_rename to fancy_replace or fancy_move
> >>  * add a 'replace' or 'move' api to transport which explicitly is
> >>    not atomic (lowest common denominator) [but is when it can be ] and
> >>    which will replace existing files or directories.
> >>  * define rename as being explicitly an atomic rename - it either
> >>    succeeds or it does not. Its behaviour with respect to existing files
> >>    and directories should then be only defined as well as we can:
> >>      + it may or may not replace existing files.
> >>      + renaming an empty directory on top of another empty one may
> >>        succeed
> >>      + renaming a non empty directory on top of another non empty
> >>        directory will not etc.

Here's a patch which adds a new Transport.rename() method, which is
required to fail if the destination is an existing nonempty directory.
This should be possible to atomically detect on all transports.  (I
don't think we can avoid overwriting existing files on on transports or
filesystems without a race.)  It also adds tests that all existing
transports actually do this.

This leaves Transport.move() with the existing meaning, which is to try
to overwrite an existing target using fancy_rename.  Keeping this there
seemed like the least intrusive change.

> I *don't* think we want to make fancy_rename a higher level than
> transport. Because then all the clients would need to know if they are
> using a Transport (or platform) which doesn't support atomic rename, and
> then they need to activate the fancy rename.

I think it's better to make it a utility which can be used by transport
implementation that need it to meet the right contract for move().
Perhaps it should be a protected Transport method.

-- 
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: transport-rename.diff
Type: text/x-patch
Size: 7359 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/0643649a/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/0643649a/attachment.pgp