Re: Case sensitivity on sftp servers

[Martin Pool <mbp%sourcefrog.net@localhost>]

On  8 Sep 2003 Joseph Galbraith <galb-list%vandyke.com@localhost> wrote:

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

Yes, the filesystem supports it, but as far as I know it cannot
usefully be accessed from applications except from in the crippled
POSIX mode.  See e.g.

  http://techsupt.winbatch.com/TS/T000001036004F26.html

In any case this is a per-filesystem option, not something that can be
specified when creating a file.  

It's hard to imagine a filesystem where you can specify that when you
create a file, though perhaps it could be supported when creating a
directory.

> I don't know about VMS?  And maybe others.

I think VMS is always case-insensitive.  

OS X is an interesting case because it commonly uses both
case-sensitive (UFS) and case-preserving (HFS) filesystems.  However
in neither case does the application get to choose which semantics it
wants.  All you can do is find out what a particular
directory/filesystem will do.  (Linux is similar, although the
case-insensitive filesystems are less often used.)

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

Yes, creating files that you can't rename or delete is not very
useful.

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

Perhaps it's easier to have clients just try it and see?  That's
simpler, more reliable and probably not too expensive.

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

On Unix this would presumably be a readonly bit?

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

I like this recommendation, but should it use SSH_FXF_EXCL as well?

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

#3 looks good to me too.

Does putting all these bits in a single attribute cause a problem when
setting the attributes?  Some clients might not have permission to set
some bits; or the bits might be readonly.  I suppose the server has to
just ignore those bits if they already have the specified values.

If you are collecting a list of bits, you might like to include some
Linux attribute bits, some of which are on other systems too.  I don't
think they're a priority for remote access, but access over filexfer
be useful for backups:

  SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY

       The file can only be opened for writing in append mode.

  SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE

       The file cannot be deleted or renamed, no hard link can be
       created to this file and no data can be written to the file.

       This bit implies a stronger level of protection than
       SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or
       ACLs.  Typically even the superuser cannot write to immutable
       files, and only the superuser can set or remove the bit.

  SSH_FILEXFER_ATTR_FLAGS_SYNC

       When the file is modified, the changes are written
       synchronously to the disk.

-- 
Martin