IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Case sensitivity on sftp servers



> You raise a good point--- hmmm... let's try this on
> for size:
> 
> new attrib bit:
> 
> SSH_FILEXFER_ATTR_FILESYSTEM
> 	string filesystem-name
> 
> SSH_FILEXFER_ATTR_FILESYSTEM is only sent by the server
> if the client requested it by including in the flags
> mask during readdir or stat operation and the file
> in question is a directory.
> 
> filesystem-name is a handle that can be passed back
> to the server using the "read-filesystem-attributes"
> It need not be human readable.

Alternatively, you could make case sensitivity directly be an
attribute of the directory, omitting a layer of indirection.  (Of
course this layer might be useful for discovering e.g. free space
later.)

> And, a new flag bit in in the modes during open to
> specify that the filename should be case sensitive
> or case insensitive.  If the server can't comply,
> it return OP_UNSUPPORTED.

I take it this is intended to control only the way the server matches
against existing filenames, and not to influence the way new files are
created?

So with case sensitivity on

  OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) 

in a directory containing "readme" ought to fail with
FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and

  OPEN("README", READ|CASE_SENSITIVE)

in a directory containing "readme" ought to fail with NO_SUCH_FILE
even on a case-insensitive filesystem?

Do you perhaps want a ternary for sensitive/insensitive/don't-care?
Some clients might be happy to use whatever the server wants.

If you give the client this option when opening files, then presumably
it should have the option for all other operations that include
filenames, including remove, rename, stat, etc.

Since it affects many operations and clients are unlikely to want to
change partway through, perhaps it should be a per-connection option?

I would like to mention that in Samba and CIFS, experience has shown
that negotiated case-sensitivity in a protocol was buggy and
surprisingly hard to implement reliably efficiently.  For example,
many Windows applications use varying case for the same file even when
NT tells them that they are not on a case-insensitive filesystem.
Doing case-insensitive compares in Unicode is not trivial and there
are implementations that get it wrong.

Adding this bit doubles or triples the testing domain for many
operations.  I would suggest not adding this option unless you're
really sure it's needed.

-- 
Martin 



Home | Main Index | Thread Index | Old Index