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.)
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