Subject: New draft-draft of sftp...

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 25 Nov 2002 14:40:28 -0700

Greetings,

Here, is a new draft-draft of the sftp draft.

Changes are a little bit more extensive than
I remembered at the meeting:

o Copied more NFS to clarify ACLs and reserved
  identifiers for the ACL who field.  Thanks
  Richard.

  (I may need to do one more round of this--
  in the context of normative vs. non-normative,
  I would prefer our NFS references to be non-normative,
  which means we have to included sufficient
  information to stand alone.  Probably a good
  idea anyway.)

o Change times to be 64 bit + 32 bit nanosecond
  field (as per decision at meeting and NFS.)

o Added additional optional extension to allow the
  server to tell the client that it compares files
  in a case insensitive way, or that files are stored
  in a case insensitive way.  Since globbing is done
  on the client, the client needs this information
  to "get it right".  In the absence of the extension,
  client is to assume 'case sensitive'.

I would like to make one more change that I know of:

o add a bit to the type field to flag whether the
  file should be hidden.  Under most unixes files
  beginning with a '.' should be hidden.  Windows
  represents this with an attribute bit.  So, only
  the server can really tell whether a given file
  should be hidden (by default) or not.

If people are okay with this I will make this change
and submit.

We are in a hurry here because we want to get this
out before we have implementers so that we don't
have to rev the version field again.

Are any of the unix implementers out there looking
at this revision any time soon?  As I mentioned at
the working group meeting, I would like to have a 
unix implementation to make sure we have made things
onerous for unix / posixish systems.

Thanks,

Joseph

---

From: Simon Tatham <[email-masked]>
Date: Tue, 26 Nov 2002 09:26:59 +0000

>   client is to assume 'case sensitive'.

Ooh, this is an interesting dilemma. The wildcard problems of SCP
begin to percolate into SFTP...

I'm not immediately disputing the usefulness of this SFTP extension,
but I'm curious to know how other people think it should be handled
in a client. Here's a pathological case to illustrate why it's non-
trivial.

I'm a client on a case-sensitive (say Unix) box, talking to a server
on a machine such as Windows, which compares filenames case-
insensitively but preserves the case they were created with. My user
asks me to retrieve `A*'. If the user hasn't twigged that the server
is case- insensitive, or perhaps hasn't twigged that a Unix SFTP
client even cares, he may be implicitly assuming that a retrieve
command with the wildcard `A*' will guaranteeably only write out
local files matching the wildcard `A*', and hence that his existing
files `averyimportantdocument', `apasswordfile' and `aroot-
privilegedstartupscript' will be safe from this command. Even if
that disaster doesn't occur, the user might still be surprised when
he exits the SFTP client and then tries to copy `A*' into some other
directory, and some of the new files don't get copied... What should
I (the SFTP client) do?

 - Go ahead and retrieve all files which _case-insensitively_ match
   `A*', and write them out with local names, hence perhaps
   overwriting those three files?
 
 - Go ahead and retrieve all files which case-insensitively match
   `A*', and convert their names into a form which
   _case-sensitively_ matches the same wildcard? This would preserve
   the user's expectations of what local files would be unaffected,
   but could quite easily confuse him in all other respects.
   Particularly when straight upper- or lowercasing isn't
   sufficient, for example if he asked for A*b*C*d.TXT...

 - Ignore the server's plea of case-insensitivity, and only retrieve
   those server-side files which case-_sensitively_ match `A*'?

 - Figure out that there's a potential problem, and issue a warning
   and request for clarification?

 - Something even more complicated?

Come to think of it, this problem already exists in current SFTP; a
client on a Windows box being asked to _send_ `A*' to a Unix server
has exactly the same set of choices, and if I'd ever got round to
implementing wildcards in PSFTP then I would already have realised
this :-) So what do existing clients do in this sort of situation?
Is there a preferred policy?

Cheers,
Simon
-- 
Simon Tatham         What do we want?        ROT13!
<[email-masked]>   When do we want it?     ABJ!