Re: Case sensitivity on sftp servers

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

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

Also, if the filesystem is different, the other characteristics
of the filesystem may also change (reserved filenames and illegal
characters.

> > 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?

No.  WinNT has the ability, at least under NTFS to
optionally support case.  I don't know about VMS?
And maybe others.

[...]

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

This would be a good idea: CASE_NATIVE.

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

I think I would tend to agree; while MS CreateFile() api does support
this, many other APIs [such as DeleteFile()] don't.

What I want is the ability to know whether or not Readme
and README are the same file.  And perhaps I don't really
care about illegal characters and names.

So, let me summerize our proposals:

Case sensitivity proposal #1, alias: the-first-cut
--------------------------------------------------
"default-fs-attribs%vandyke.com@localhost" --
   o deal with only the system native case-sensitivity.
   o can't deal with multiple filesystem handling case differently.
   o can't deal with filesystems where case sensitivity is optional.


Case sensitivity proposal #2, alias: the-whole-enchillada
---------------------------------------------------------
"filesystem-name" + "read-filesystem-attributes"
   o deal with case sensitivity on a per directory bases,
     so multiple filesystems are handled.
   o Case sensitivity can be specified during open
   o Probably needs to specify sensitivity during delete/rename/etc.,etc.
   o Probably hard to implement and get reliable (based on Samba/CIFS experience.)

Case sensitivity proposal #3, alias: the-lean-mean-case-sensitive-machine
-------------------------------------------------------------------------
(And also deals with other issues on my list):

New attrib bit: SSH_FILEXFER_ATTR_FLAGS

The 'flags' field is any combination of the following bits:
    SSH_FILEXFER_ATTR_FLAGS_READONLY
        Advisory readonly bit.  This bit is not part of the
        access control information on the file, but is rather
        an advisory field indicating that the file should not
        be written.

        For example, some source code control systems use this
        bit to indicate that the file is not locked, and therefor
        should not be modified.  When the file is locked, the bit
        is cleared.

    SSH_FILEXFER_ATTR_FLAGS_SYSTEM
        The file is part of operating system.

    SSH_FILEXFER_ATTR_FLAGS_HIDDEN
        File should not be shown to user unless specifically
        requested.  For example, most unix systems should set
        this bit if the filename begins with a 'period'.

    SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE (directory only)
        Files & directory names in this directory should be compared with-out
        regard to case.

        It is recommended that where possible, the filesystem be allowed to
        do comparisons.  For example, if a client wished to prompt a user before
        overwriting a file, it should not compare the new name with the previously
        retrieved list of names in the directory.  Rather, it should first try to
        create the new file by specifying SSH_FXF_CREAT without the SSH_FXF_TRUNC
        flag.  Then, if this fails and returns SSH_FX_FILE_ALREADY_EXISTS, it
        should prompt the user and then retry the create specifying SSH_FXF_TRUNC.

        The case insensitive flag should only be used to implement name globbing
        or other filename based filtering systems.

        Unless otherwise specified, filenames are assumed to be case sensitive.

    SSH_FILEXFER_ATTR_FLAGS_ARCHIVE
        The file should be included in backup / archive operations.

    SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED
        The file should be encrypted.  If the filesystem doesn't support
        encryption, the operation must return UNSUPPORTED.

    SSH_FILEXFER_ATTR_FLAGS_COMPRESSED
        The file should be compressed.  If the filesystem doesn't support
        compression, the operation must return UNSUPPORTED.

    SSH_FILEXFER_ATTR_FLAGS_SPARSE_OPTION
    SSH_FILEXFER_ATTR_FLAGS_SPARSE_REQUIRED
        The file should be sparse.  If SPARSE_REQUIRED is specified, the operation
        MUST fail if it is not supported.

My preference at this point leans toward #3.  Do any other implementors
supporting other operating systems have bits that would be appropriate
for this field?

- Joseph