Re: New draft-draft of sftp...

[Jeffrey Altman <jaltman%columbia.edu@localhost>]

I recommend that people take a look at the archives for the last three
months in the FTP-EXTS working group mailing list.  This discussion is
going to be a direct parallel to the discussions that took place there
regarding the switch from server side pattern matching to client side
pattern matching with the MLSD.  

Basically the end result is that for each file system on the host the
client is going to need to know whether or not the file system is
case-sensitive or not.  Plus the client needs to know which characters
are treated as special in the file system.  And which are illegal.
All of this is required for the client to have a chance to properly
perform matching against server generated file names.

In the FTP MLSD case, the FTP EXT group is arguing that the pattern
matching rules that are to be applied are those of the client system
and should only be applied after receiving from the host the complete
list of file names.  Therefore, host characteristics do not apply.

Unfortunately, this argument fails on its face if you want to be able
to script an operation that attempts to send a file to the host 

  filename

but the remote file system stores it as 

  FILENAME

so the check to see of the file arrived fails because the remote
server is not performing the check.  

The Kermit project believes that globbing must be performed on the
server.  



> Joseph Galbraith <galb-list%vandyke.com@localhost> wrote:
> > 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'.
> 
> 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!
> <anakin%pobox.com@localhost>   When do we want it?     ABJ!
> 


 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 kermit-support%columbia.edu@localhost               OpenSSL.