Subject: RE: Case sensitivity on sftp servers

From: Richard Whalen <[email-masked]>
Date: Fri, 5 Sep 2003 13:39:58 -0400

Though I agree that specifying case sensitivity may be useful, I think that
specifying it on a server wide basis is too broad.

The server may offer several file systems and some of these may not preserve
case, while others may preserve case but not be case sensitive, and still
other may preserve case and be case sensitive.

The server may also have the option of allowing the client to specify
whether or not file operations are case sensitive on a file system that
preserves case.

It may be necessary to specify a method of obtaining the file systems
available and their characteristics (Read Only, Case Preserving, Case
Sensitive, etc.)

----------------------
Richard Whalen
Process Software
508-879-6994x261

-----Original Message-----
From: Joseph Galbraith [mailto:[email-masked]]
Sent: Friday, September 05, 2003 1:04 PM
To: [email-masked]
Subject: Case sensitivity on sftp servers

We never reached consensus on the issue
of the server advertising whether or not
files where case sensitive or not.

I think it is a good idea for the server to
tell the client about case sensitivity because:

o For globbing purposes, the client may need to
   know, depending on how the user wants to operate,
   whether a* matches Alphabet.txt on the server.

   I claim we are not smart enough to know all the
   ways people will want to use SFTP and therefor
   not smart enough to say that they will all be
   happy with globbing that uses the case rules of
   their client.

o When transfering files between a client and server
   with different case properties, the client may
   wish to warn the client about problems (instead
   of overwriting just transfered data or giving the
   user an overwrite prompt.)  The client might also
   wish to help the user resolve the problems (automatic
   renaming algorithms, or some kind of conflict resolution
   interface.)

   These kinds of things would be made easier by the client
   understanding that two different files on the server
   have the same name on the client.  Or, two different files
   on the client have the same name when transfered to the
   server.

Do we want to solve these problems in the sftp draft?

VanDyke has solved these problems between our
own clients and servers using the following
extension:

string "[email-masked]"
string attrib-packet
     uint32 file-system-attribute-mask
     string illegal-characters [UTF8]
     uint32 reserved-name-count
         string reserved-name[1] [UTF8]
         ...
         string reserved-name[reserved-name-count] [UTF8]

file-system-attribute-mask
     Any combination of the following:

         SFTP_FSATTR_CASE_PRESERVED    = 1
         SFTP_FSATTR_CASE_SENSITIVE    = 2

illegal-characters
     Characters that can not be used in a file or directory name.

reserved-name-count
reserved-name
     Names that cna not be used for a file or directory.  For example,
     under WinNT, these include COM1, COM2, etc.

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 05 Sep 2003 14:37:43 -0600

> available and their characteristics (Read Only, Case Preserving, Case

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.

-- 
byte   SSH_FXP_EXTENDED
uint32 request-id
string "read-filesystem-attributes"
string filesystem-name

byte SSH_FXP_EXTENDED_REPLY
uint32 request-id
uint32 file-system attribute flags
	CASE_SENSITIVE
	CASE_PRESERVITIVE
	CASE_OPTIONAL
string-utf8 invalid-chars
uint32 reserved-name-count
string reserved-name[1..reserved-name-count]

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.

What do you think?

I think I keep the "default-file-attributes" and then
the filesystem only need be sent if it is different from
the default.

- Joseph