IETF-SSH archive

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

RE: sftp rename not good.



At 06:01 PM 5/13/2003, Howard Chu wrote:

> -----Original Message-----
> From: ietf-ssh-owner%netbsd.org@localhost [mailto:ietf-ssh-owner%netbsd.org@localhost]On Behalf
Of Nicolas Williams

> On Tue, May 13, 2003 at 05:29:51PM -0600, Dan O'Reilly wrote:
> > At 05:20 PM 5/13/2003, Nicolas Williams wrote:
> > >On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote:
> > > > Now that scares me. :)  My intention was to gather
> support for UNIX
> > > > semantics for this, not "whatever rename(2) does on the server".
> > >
> > >If the semantics of file renaming vary so much from platform to
> > >platform, without even the ability to reliably emulate one
> behaviour on
> > >all those platforms, then either that variance will have to carry
> > >through to SFTP or the SFTP server will have to have a way
> to tell the
> > >SFTP client what file rename semantics it supports so the
> client can
> > >choose which to use.
> >
> > Why should the client care at all?  The basic requirement
> is "support a
> > rename function".  Why should the client *SOFTWARE* (not
> USER) care how
> > the server system actually performs that?  A VMS system
> should be allowed
> > to behave as a VMS system should when renaming a file; as
> should a UNIX
> > system or a Windows system.  That's not client-specific.
>
> If the client doesn't care, then the semantics of rename
> should be upto
> the server (within some parameters? which parameters?).
>
> But I think the client cares, or, rather, this user cares :) :)

I think that can be accomodated... If you are a VMS user, then you're already
familiar with how "rename" behaves on your VMS system. You could reasonably
expect that when you ftp/sftp to your system and perform a rename, the same
semantics that you already expect, are carried out. Likewise if you're a Unix
user connecting to a Unix server.

I don't believe there's any mechanism for the client to connect to an
arbitrary server and say "I expect Unix semantics" though, nor do I think
there should be. When you're connecting to a foreign system, you get the
semantics that system supports. What's the big problem with that? I recall
countless ftp sessions to TOPS-20 servers and IBM mainframes, with their
weird 9-bit-per-byte words or their record-oriented filesystems. If you try
to force every system into a Unix-like interface, you make it impossible to
exchange files with these systems, that have no notion of flat octet-stream
files.

Putting an artificial Unix-like wrapper over things seems like the wrong
approach. If I'm using VMS, I want my tools to act like every other VMS tool.

Bless you, my son...<grin>...

Seriously, I'm not trying to take a VMS-centric approach here.  What I *am*
saying is there are more filesystems out there that are different from the
say UNIX does things.  A truly flexible approach allows for that.

------
+-------------------------------+----------------------------------------+
| Dan O'Reilly                  |  "There are 10 types of people in this |
| Principal Engineer            |   world: those who understand binary   |
| Process Software              |   and those who don't."                |
| http://www.process.com        |                                        |
+-------------------------------+----------------------------------------+





Home | Main Index | Thread Index | Old Index