Subject: Re: sftp rename not good.

From: Alfred Perlstein <[email-masked]>
Date: Tue, 13 May 2003 11:54:43 -0700

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 <[email-masked]> [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 [email-masked].  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 [[email-masked]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'

---

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 13 May 2003 13:28:41 -0600

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

---

From: Simon Tatham <[email-masked]>
Date: Tue, 13 May 2003 21:03:16 +0100

Joseph Galbraith <[email-masked]> wrote:
> - 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.
> 

AIUI, that's only half the problem. The other half is that
SSH_FXP_RENAME can't be used to implement rename(2)!

The rename(2) semantics are useful if you want to avoid race
conditions with other processes reading a file: you create a new
version of the file under a different name, and atomically rename(2)
it over the top of the old one, and at _all_ observable instants on
the server there is a file with valid contents stored under the
original name. I believe it's being asserted that this would be a
useful feature in SFTP.

Cheers,
Simon
-- 
Simon Tatham         "Thieves respect property; they only wish the property to
<[email-masked]>    be their own, that they may more properly respect it."

---

From: Alfred Perlstein <[email-masked]>
Date: Tue, 13 May 2003 14:57:56 -0700

> Is this a correct summary of the problem?

That's the cause of the problem.

The actual problem is that it doesn't seem possible to do atomic
updates of files using sftp because of the way SSH_FXP_RENAME must
be implemented.

Also, I _think_ that using link(2) (without fsync) instead of
rename(2) allows for the system to lose the file completely
during an outtage.

I think there should be some way of invoking an actual rename(2)
on the server.

thank you,
-Alfred

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 16:14:55 -0600

>I think there should be some way of invoking an actual rename(2)

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.

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

---

From: Alfred Perlstein <[email-masked]>
Date: Tue, 13 May 2003 15:22:37 -0700

> so the behavior of a rename on VMS could be drastically different than

Now that scares me. :)  My intention was to gather support for UNIX
semantics for this, not "whatever rename(2) does on the server".

-Alfred

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 16:26:05 -0600

>semantics for this, not "whatever rename(2) does on the server".

Well, the point is, not everything is UNIX (and Lord knows, that whole
subject has come up before!).  If you allow it to be server-based, then
the whole issue of "how do I do a rename" is obviated from the client's
perspective.  Makes things cleaner all around, I think.

------

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 May 2003 01:06:45 +0200

> Is this a correct summary of the problem?

yes, and the usual unix semantics for 'move'
cannot be easily emulated with SSH_FXP_RENAME.

-m

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 May 2003 09:10:27 +1000

> so the behavior of a rename on VMS could be drastically different than

Please no! Protocol methods should be specified to behave in a
particular way, regardless of what server environment is in use.

A "protocol method with unix-like rename semantics" has some merit though.

-d

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 May 2003 09:13:49 +1000

> rename(2) allows for the system to lose the file completely

No, there is always at least one link to the file during the usual
sequence of events:

if (!exists(new))
	link(old, new)
	unlink(old)

Unless you are using some idiot filesystem that writes out directory
changes asynchronously (not mentioning any names...)

-d

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 16:20:50 -0700

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

Cheers,

Nico
--

---

From: Alfred Perlstein <[email-masked]>
Date: Tue, 13 May 2003 16:26:44 -0700

> changes asynchronously (not mentioning any names...)

What you have there is atomicity, not durability.

You must fsync(2) either "dirname(new)" or possibly "new" after the
link(2) for that to be safe, otherwise you are relying on the
filesystem's implementation.

Only rename(2) has the semantics you actually want without the need
for fsync(2).

-Alfred

---

From: Alfred Perlstein <[email-masked]>
Date: Tue, 13 May 2003 16:32:57 -0700

> SFTP client what file rename semantics it supports so the client can

Which is why I was hoping for "rename -f" to at least attempt the unix
rename(2).  If rename(2) is not available it should do something like 
this:

if (rename(old, new) == -1)
	if (errno != ENOSYS || errno != ENOTSUP)
		return (-1);
	/* emulate rename, XXX: output a warning to client? */
	(void) unlink(new);
	if (link(old, new) != 0)
		return (-1);
	if (fsync(new) != 0) {
		(void) unlink(new);
		return (-1);
	}
	(void) unlink(old);
}

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 17:27:38 -0600

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

------

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 17:29:51 -0600

>SFTP client what file rename semantics it supports so the client can

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.

------

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 16:35:08 -0700

> 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 :) :)

Cheers,

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 May 2003 09:41:35 +1000

Dan O'Reilly wrote:
> the server system actually performs that? 

Because the semantics matter: will the server's rename() overwrite an
existing file? Is it atomic? Will it cross filesystems?

Put a different way: if the semantics are irrelevant, then why are we
even having this discussion?

-d

---

From: Ben Lindstrom <[email-masked]>
Date: Tue, 13 May 2003 18:47:54 -0500 (CDT)

> even having this discussion?

I agree.  It does matter.  One person's definition and implement of what
'rename' does and does not do can be very different than someone elses.
And without some constant baseline to work from it will drive the user
insane.

Lot of places deploy ssh/sftp instead of ftp for website updating.  And
frankly, most end-users don't care why NT acts one way and VMS works
another.

- Ben

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 13 May 2003 17:01:07 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
Of Nicolas Williams

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

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 18:19:16 -0600

>But I think the client cares, or, rather, this user cares :) :)

Well, actually, I agree with you, and you've made my point.  The client
doesn't care, but the user does.  And a user on a VMS system will expect
to see things done the way VMS does things, just as a user on a UNIX
system will expect to see things done with way UNIX does things.  So, if
the functionality is left up to the server, it accomplishes that quick
nicely.

I can tell you a common complaint we hear from our users is "why doesn't
this work on VMS as I would expect it to?".  I'm thinking "preemption"
here.  Let the servers work as the servers will, and have the protocol
simply specify "you must support a rename function" (or whatever other
function is at hand).

------

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 18:21:31 -0600

>even having this discussion?

Because somebody is trying to make the semantics relevant in a VERY
system-specific (i.e., UNIX) way.  I'm trying to make the semantics
irrelevant as I believe they should be.  Why should I care how UNIX does
a rename function versus VMS?  The important thing is that the rename
occurs.

For example: in UNIX, it may be illegal to rename a file if one of the
same name exists.  In VMS, it may or may not be illegal, depending on
if file versions are specified for the complete file specification supplied
to the rename function.

------

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 18:22:20 -0600

>frankly, most end-users don't care why NT acts one way and VMS works

Exactly my point.  They don't care.  So let the systems do the work the
way they're designed to do it!

------

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 18:24:01 -0600

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

------

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 18:40:05 -0700

> the functionality is left up to the server, it accomplishes that quick

Quite convincing.  I'm afraid that scripted clients may nonetheless need
to know what semantics are implemented on the server side, or at least
what platform it is.  But overall I agree with you, let the server do as
it will, and possibly, give the client a hint.

Cheers,

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 May 2003 11:49:43 +1000

>>even having this discussion?

[...]

> if file versions are specified for the complete file specification supplied

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.

This would break, among other things, scripted/automated applications
and would be a step back from where we are now (where we at least know
the semantics of sftp's rename method).

-d

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 18:55:59 -0700

> the semantics of sftp's rename method).

Unless a) the server can tell the client what semantics to expect and b)
the client can use that information to work in all cases; the sticking
point is likely going to be about atomicity, but there's no guarantee
that any user-land SFTP server implementation can provide atomicity on
platforms that normally don't.

As others have pointed out, humans may well cope with these variations
in rename semantics, and as you point out it's the scripts that will
have trouble - but can they be made to cope?

Nico
--

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 20:18:21 -0600

>it will, and possibly, give the client a hint.

I've often wondered why there wasn't a provision for that "hint"; some sort
of optional part of some initialization message that the server could use
to inform the client (and, I suppose, vice-versa) of what system is
running.  I have to believe there would be some good uses for that.

------

---

From: "Dan O'Reilly" <[email-masked]>
Date: Tue, 13 May 2003 20:22:53 -0600

>the OS-supplied function, we would have clients that behave differently

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 semantics of sftp's rename method).

How would it break them?  I've seen that said, but nobody's done anything
to show how it would break them.  Besides, if you're going to a VMS
system, don't you, as a user, kind of implicitly have to KNOW that if
you're getting into some esoteric scripted stuff?  You see what I'm saying,
I hope: your solution is "treat everything as UNIX, regardless of what
it REALLY is".  And I'll make the point that the only supported (offically)
sftp server in existence today is from my company anyway.  There's not a
whole heckuva lot of scripted stuff going to VMS, because it's brand new
for that system (and I mean that literally).  So, the idea of "it'll break
scripted applications" is somewhat specious, since for VMS, they simply
don't exist yet!

------

---

From: Jon Bright <[email-masked]>
Date: Wed, 14 May 2003 08:45:12 +0200

> Why in the world would the CLIENT behave differently?  The client says

I think you'd have to admit that for the Client's purposes, it's 
interesting to know whether a rename is going to overwrite an existing 
file or not.  Irrespective of the Unix and VMS ways of doing things, it 
seems sensible to have a normal rename (which refuses to overwrite 
existing files) and a rename -f (which will overwrite where 
appropriate).  *How* the server goes about providing those two very 
generalised facilities is a matter for the server...

--
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Pontus Skoeld <[email-masked]>
Date: 14 May 2003 08:48:01 +0200

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

(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).

Also, I think not specifying the semantics would make it harder to
implement things like file system drivers (for mounting sftp sites as
normal filesystems) and guess it could mean it takes even longer
before programs like Adobe GoLive and Dreamweaver get sftp support,
both those things are bad.

That said, I do of course encourage everyone to make sure that we end
up with good, useful semantics.

	/Pontus
-- 

Pontus Sköld, see <URL:http://soua.net/> for more information.

---

From: Alfred Perlstein <[email-masked]>
Date: Wed, 14 May 2003 00:01:30 -0700

> running.  I have to believe there would be some good uses for that.

Isn't that somewhat like what ftp does?  Afaik you used to see
something like "remote system is UNIX" when logging in, maybe that
was just infomative and not part of the spec though.

-Alfred

---

From: "Howard Chu" <[email-masked]>
Date: Wed, 14 May 2003 00:05:02 -0700

> From: [email-masked] [mailto:[email-masked]]On Behalf
Of Pontus Skoeld

> from a UN*X box to a VMS server.

This statement implies a situation where the client is not expected to know
anything about the remote server. In practice, this situation is
non-sensical. You cannot connect to the server in the first place unless
you're either a regular user of that system, or you have made a special
pre-arrangement to obtain an account on that system. You certainly won't have
write privileges to rename arbitrary files on a server that is completely
unknown to you. Theoretical discussions about what might cause problems may
be an interesting intellectual diversion, but they are just that -
*diversions*. Real users will have knowledge about the remote server that
they're operating on.

To assume the client has no knowledge of the server is pointless.

  -- Howard Chu

---

From: Richard Silverman <[email-masked]>
Date: Wed, 14 May 2003 03:30:58 -0400 (EDT)

I think this disagreement reflects a more basic difference of opinion on
the purpose of the sftp protocol, which needs to be resolved.  One side
views sftp as defining a fully abstract storage mechanism, having its own
internally consistent semantics which all compliant implementations must
uphold.  The constraint might be stated thus:

"Given a sequence S of sftp operations, and an sftp-observable initial
state I, the sftp-observable result state R of executing S from I must be
the same on any implementation."

In other words, one purpose of sftp is to hide the details of server host
operation in favor of a predictable storage abstraction.

The other side of the fence says no, no -- the purpose of sftp is to
provide convenient remote manipulation of a host's filesystem, in such a
way as to be as familiar as possible to users of the host OS.  Thus, each
implementation should be free to choose mappings of basic sftp operations
(such as SSH_FXP_RENAME) onto the server's filesystem primitives, in a way
its authors think will be most useful and familiar to users.  In
non-obvious cases, users will have no way of knowing what the mapping will
be, short of reading the software documentation (not the protocol spec),
or just trying it out.

Dan O'Reilly points out that this is what many of his users expect -- the
underlying assumption here is that the "user" is first and foremost a user
of the host OS, merely employing sftp as a way to get at some files when
not directly logged into the host.  While I agree this is a common
scenario, it is not the only one.  Equally valid is the following: the
user employs an sftp client as his *sole* method of accessing some file
store; he has never logged into the host, nor does he know or care what OS
it's running.  One day, the systems department replaces the server with a
new machine running a different OS, but also with an sftp server.  Our
putative user then performs some sequence of file manipulations he's done
many times before -- but gets different results!  He screams, because
wasn't using a consistent abstraction supposed to protect him from this
sort of thing?  Well, that's the question: is sftp supposed to afford such
protection, or not?

Despite the inherent elegance of a fully-abstract model, and its
advantages in some situations, I have to (reluctantly) say that model #2
is probably the way to go, for a number of reasons:

1) The sftp spec as it stands does not articulate or support viewpoint #1
   at all.  There is no requirement for fully abstract operation, and in
   fact, there is recognition of the opposite principle; from section 6.2
   (File Names):

   "... It is understood that the lack of well-defined semantics for file
    names may cause interoperability problems between clients and servers
    using radically different operating systems.  However, this approach
    is known to work acceptably with most systems, and alternative
    approaches that e.g.  treat file names as sequences of structured
    components are quite complicated."

2) The two models solve related but different problems.  One is remote
   access to different filesystem types via a usable
   least-common-denominator protocol, which will necessarily have some
   limitations.  The other is defining a consistent, server-independent
   remote filing protocol.  While the second problem is valid and could
   use a solution, I think in reality sftp is more geared toward solving
   the first.

3) The fully-abstract requirement will severely limit and complicate
   implementation.  For example, the Mac OS X HFS+ filesystem is
   case-preserving but not case-sensitive.  In a directory containing
   files "foo" and "bar", the result of renaming "foo" -> "Bar" using
   naive server-side semantics is going to be *very* different from what a
   user of a traditional Unix system would expect!  If abstract operation
   required case-sensitivity, how would you implement that on the server?
   And would it make any sense to someone logging into the server and
   viewing the result?

4) Given that people *will* be accessing files both via sftp and via the
   host OS, it gets worse -- even if the fully-abstract requirement stated
   earlier is met, there's no guarantee the user will be happy with the
   server-side result.  For example: NTFS allows multiple streams per
   file.  Sftp has no notion of that, and I imagine that all extant
   Windows sftp implementations simply read stream 0.  The sftp operation
   sequence "create bar; open foo; read foo; write bar; delete foo" will
   be sftp-observably identical to "rename foo -> bar" (atomicity and
   concurrency issues aside for the moment)... but again with naive
   server-side semantics, one will probably end up trashing a multi-stream
   file, while the other preserves it.

- Richard Silverman
  [email-masked]

---

From: Richard Silverman <[email-masked]>
Date: Wed, 14 May 2003 03:41:19 -0400 (EDT)

> To assume the client has no knowledge of the server is pointless.

I completely disagree with this statement.  It is a perfectly possible to
give someone an account on a system for the sole purpose of (and limited
to) sftp access.  The user may never log into the directly, or even know
what the host OS is or how to use it; it acts as an opaque sftp file
server.  This situation is neither nonsensical nor pointless; on the
contrary, it is useful and reasonably common, follows normal and useful
principles of abstraction, and is likely to become more common as sftp
becomes more widely implemented.

- Richard Silverman
  [email-masked]

---

From: "Howard Chu" <[email-masked]>
Date: Wed, 14 May 2003 01:03:17 -0700

> From: Richard Silverman [mailto:[email-masked]]

> becomes more widely implemented.

Yes, it is possible to do what you describe. It is also possible for the user
to call you up when they have a problem or get confused. Legitimate users
have access to information about the system they're using, because they have
access to whoever gave them the account in the first place. As I said, the
client is either a regular user or has gotten pre-arranged access to the
server. If you're giving out accounts to your server, you should expect to
provide support for those accounts, even if "support" consists merely of a
README file. If you hand out accounts to users without telling them how to
use them, you have a different problem, and that's certainly outside the
realm of SSH to address.

  -- Howard Chu

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 May 2003 18:37:42 +1000

Howard Chu wrote:
> non-sensical. 

That is bogus: many ISPs and hosting providers provide ssh and sftp
access to their servers without disclosing details about the OS
environment. All the user knows is an IP address, a username and a password.

Chances are, right now, that these are running an Unix-like OS of some
sort, but there are no guarantees.

-d

---

From: "Howard Chu" <[email-masked]>
Date: Wed, 14 May 2003 01:57:06 -0700

> From: [email-masked] [mailto:[email-masked]]On Behalf
Of Damien Miller

> sort, but there are no guarantees.

Details, no. But everyone operates under a certain set of assumptions. This
works today precisely because the vast majority of SPs use Unix servers. And
most ISPs explicitly advertise "Unix hosted" or "Windows hosted" or whatever,
it's a selling point in itself.

If you sign up with an ISP and all they give you is an IP address, username,
and a password on an IBM mainframe running OS/390, with a "home directory"
residing in a partitioned data set, you can bet that (a) all of your unspoken
assumptions about how the host behaves will be wrong and (b) you will need to
call tech support very early on.

The vast majority of The Internet today runs on Unix systems, using
hierarchical filesystems with forward-slashes as pathname separators, and so
a majority of people are accustomed to working with their servers in a
particular manner. Even if no one handed them docs for it, that does *not*
mean they have zero information about the server, it means they're operating
on implicit information. There's a big difference between that and using a
system with zero information.

You cannot use a server without knowledge of how the server behaves. When you
are a legitimate user of a server, you also have legitimate access to
information about the server - whoever provides your account has no choice
but to give you this information. The information may just be "it works just
like your PC" or it may be a detailed guidebook, but the information is there
nonetheless.

  -- Howard Chu

---

From: Ben Lindstrom <[email-masked]>
Date: Wed, 14 May 2003 08:19:43 -0500 (CDT)

[..]
> both those things are bad.

Dreamweaver MX supports sftp.

- Ben

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 May 2003 07:16:46 -0700

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

> track of server peculiarities and work around those).

Atomicity differences may not be possible to hide.

Nico
--

---

From: "Joseph Galbraith" <[email-masked]>
Date: Wed, 14 May 2003 09:29:28 -0600

> becomes more widely implemented.

Precisely.

Much of this discussion has focused around one type
of user.  The VMS user sitting someplace else accessing
his VMS files remotely.  (Replace VMS with any other operating
system you'd like, in both places.)

In practice, I see at least one other scenerio is extremely
common.  The Windows user, sitting at a windows box, accessing
files on some other platform.  For example, managing a website
on a unix server.  This user has some minimal experience on the
host operating system, but is not and doesn't want to be intimately
familar with the host operating system.  And the question they ask
me, is "Why doesn't it behave just like every other windows program."

It is a reasonable expectation: the sftp client they are running is a
windows program.  It presents their files like windows does.  They
have every right to expect it to manipulate those files in the manner
they are most familar with: windows.

(Again, substitute windows in all locations with any other OS of your
choice.)

- Joseph