Re: sftp rename not good.

[Dan O'Reilly <dano%process.com@localhost>]

At 05:10 PM 5/13/2003, Damien Miller wrote:
> Dan O'Reilly wrote:
> > At 03:57 PM 5/13/2003, Alfred Perlstein wrote:
> >>* Joseph Galbraith <galb-list%vandyke.com@localhost> [030513 12:28] wrote:
> >>I think there should be some way of invoking an actual rename(2)
> >>on the server.
> >
> > That would be best, IMHO.  That way, you can implement server-specific
> > behavior.  For example, those of us on VMS have versioned file systems,
> > so the behavior of a rename on VMS could be drastically different than
> > that on a UNIX system.
>
> Please no! Protocol methods should be specified to behave in a
> particular way, regardless of what server environment is in use.

Why should a protocol specify more than "you must support a rename function
in the server", without specifying specifics of the implementation?  To do
other than that is to restrict a server and to possibly limit it in its
functionality vis-a-vis a normal (e.g., ftp) file system operation.

By specifying that a function must be supported (e.g., "you have to be
able to rename a file") but not HOW it must be supported (e.g, in VMS you
can create another file of the same name with a new version number, or you
could simply replace an existing file), you provide the maximum flexibility
while still hiding the specifics of the host system operating system and/or
file system.  And that, I was always given to understand, is the definition
of "flexible" in a protocol.  Why should every OS and every file system
conform to a UNIX (or Windows or ????) "standard" when it inherently limits
the functionality of those systems?

------
+-------------------------------+----------------------------------------+
| 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        |                                        |
+-------------------------------+----------------------------------------+