IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sftp rename not good.



On Wed, May 14, 2003 at 08:48:01AM +0200, Pontus Skoeld wrote:
> "Dan O'Reilly" <dano%process.com@localhost> writes:
> 
> > >So if we followed you suggestion and had sftp's rename method simply use
> > >the OS-supplied function, we would have clients that behave differently
> > >depending on the server.
> > 
> > Why in the world would the CLIENT behave differently?  The client says
> > "rename this file".  The server does so, according to the rules of the
> > system that the server is running on.  Case closed.  The client doesn't
> > have to know *ANYTHING* about what the server is doing.  Perhaps the
> > USER might, but not the client itself.
> 
> The client may try to hide the sftp protocol and act like the user
> expects her normal system to act, which is probably what matters to
> her. She shouldn't need to know if someone decides to move her files
> from a UN*X box to a VMS server.

Even on one platform some filesystem semantics can change from one fs
type to another (think NTFS vs. FAT32 or UFS vs FAT floppies).  Why
should the client try so hard to hide the differences?

And SFTP is not a remote file system protocol; you can use NFSv4 if what
you want is a multi-platform file system protocol.

SFTP already borrows from NFSv4; perhaps this tradition should be
followed in this case: what's good for NFSv4 should be good for SFTP.

> (I'm not sure whatever that answers your question, but if the client
> wants to present a consistent "user experience", it would have to keep
> track of server peculiarities and work around those).

Atomicity differences may not be possible to hide.

Nico
-- 



Home | Main Index | Thread Index | Old Index