IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New draft-draft of sftp...
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!
Home |
Main Index |
Thread Index |
Old Index