Re: sftp rename not good.

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

Let me make sure I understand the problem:

- SSH_FXP_RENAME specifies that it is an
  error if the new file exists.

- rename(2) specifies that if the new file
  exists, it is always overwritten.

Therefore rename(2) can't be used to implement
SSH_FXP_RENAME.

Is this a correct summary of the problem?

Thanks,

Joseph

----- Original Message ----- 
From: "Alfred Perlstein" <bright%mu.org@localhost>
To: <ietf-ssh%netbsd.org@localhost>
Cc: "Markus Friedl" <markus%openbsd.org@localhost>; <openssh%openssh.com@localhost>
Sent: Tuesday, May 13, 2003 12:54 PM
Subject: Re: sftp rename not good.


> 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.'
> 
>