Re: sftp rename not good.

[Alfred Perlstein <bright%mu.org@localhost>]

Basically we're having a discussion about why rename under sftp
doesn't provide true rename(2) semantics.  Can someone comment
or provide a suggestion to resolve this?  I have several
half-baked solutions at the end of this email to choose from
or a new idea would be welcome.

thank you,
-Alfred

* Markus Friedl <markus%openbsd.org@localhost> [030513 08:33] wrote:
> On Tue, May 13, 2003 at 04:19:17AM -0700, Alfred Perlstein wrote:
> > I was trying to use sftp to upload pictures for a camera project
> > and came across a problem, basically the rename code is trying
> > to be clever for some reason that I can't determine and is broken
> > for renaming a file over an existing one:
> 
> but this is how it's supposed to work:
> 
> 6.5 Removing and Renaming Files
> 
>    ....
...
>    where `id' is the request identifier, `oldpath' is the name of an
>    existing file or directory, and `newpath' is the new name for the
>    file or directory.  It is an error if there already exists a file
>    with the name specified by newpath.  The server may also fail rename
>    requests in other situations, for example if `oldpath' and `newpath'
>    point to different file systems on the server.
...
> > Why not just use rename(2)?  Or fall back to rename(2) if on unix
> > or if the link fails?  If the "race" is that there may be data 
> > lossage then this is pointless unless you fsync the target files
> > between operations.
> 
> The original code was 
...
> }
> 
> but since newpath might be created after the stat(2)
> we changed this to the current code.
> 
> however, i think that for the traditional unix 'mv', this
> specification of SSH_FXP_RENAME is bogus, so you should
> talk to ietf-ssh%netbsd.org@localhost.  any other ideas?
> or am i missing something.  a rename(2) semantic would
> be much better....

I totally agree that having a true mechanism for getting
real rename(2) semantics is desireable.

Perhaps a flag though, rename -f or something to do an actual rename
or perhaps a "-i" for the link(2) behaviour.  Or maybe adding the
ability for the built in "ln" command to do hardlinks then if the
user wanted the current behaviour they could just use "ln". :)

Just some suggestions.

-- 
-Alfred Perlstein [alfred%freebsd.org@localhost]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'