Re: Case sensitivity on sftp servers

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

Martin Pool wrote:

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

Actually, the Win32 CreateFile() api takes a flag:

FILE_FLAG_POSIX_SEMANTICS
    Indicates that the file is to be accessed according
    to POSIX rules. This includes allowing multiple files
    with names, differing only in case, for file systems
    that support such naming. Use care when using this
    option because files created with this flag may not
    be accessible by applications written for MS-DOS or
    16-bit Windows.

So it is accessable from Win32 (not just from the posix subsystem)
and can be specified when creating the file.  I'm not sure when this
flag was introduced; it may have been with windows 2000.

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

Unfortunately, I don't think Win32 offers support
for creating case-sensitive directories.  Or for
any other case-sensitive operations.  Though if
you are willing to go straight to the NT API
(as opposed to the Win32 API) I'm quite sure
that you can do any file operation you want in
either a case sensitive fashion or case insensitive.

(Provided of course, you are working with an NTFS
partition or some other filesystem that can support
both.)

> [...]

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

Yes, I would think so.

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

Yes, you are correct.

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

Well, it means you probably have to read the mask before
you write it (like mode bits if you only want to change
the other permissions.)

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

Excellent; I'll add these-- being able to do good backups is one
of the applications that has been on my mind.

Thanks,

Joseph