Re: Text file type hint proposal for filexfer

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:
> How about this alternative-- sftpv5 has (and naturally v6 will have)
> an 'attrib-bits' field in the attrib structure which describes various
> bit attributes, such as case-sensitivity, if the file is encrypted on
> disk, compressed on disk, advisory readonly, a hidden file, a system
> file, etc.

Yes, that's fair enough. I just recycled my proposal from SFTP v4
without taking account the new attrib-bits field. This information is
probably better there.

It might be worth spelling out that in the absence of either of these
bits being set, the client SHOULD NOT automatically assume anything
about the textiness or otherwise of the file. (The user can tell it, of
course.)

> What if we add two bits there:
> 
>      #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT      0x00000800
> 
>         The server is reasonably certain that the file
>         contains textual data, and therefore the file
>         should be opened in text mode.
> 
>         This flag MUST NOT be present during a setstat operation.
>         If this flag is present during an fsetstat operation,
>         the file handle is converted to a text-mode handle, as
>         if it had been opened with SSH_FXF_ACCESS_TEXT_MODE.

(Hmm. I deliberately hadn't ruled out the possibility that the "text
flag" corresponded to some state on the server that you might want to be
able to set with setstat. However, I'm not strongly wedded to that idea;
it's probably a bit kludgy when you consider a filesystem that can
represent a range of file types but only has this single distinction
exposed over SFTP.)

It seems a bit kludgy to override fsetstat's semantics in this way, when
all other attributes correspond to state on disc. I think I'd prefer
some new freopen()-like operation to change the file open mode.

This however doesn't get round Richard Whalen's VMS concerns, except
that perhaps being able to say SSH_FX_OP_UNSUPPORTED without ambiguity
as to _what_ precisely is unsupported might be helpful (unlike setstat,
where any of the attributes could have upset the server)?

Perhaps the new `reopen' operation could be an extension, so that its
lack on servers like VMS will be obvious up front via the "supported"
extension, rather than the client not finding out until halfway through
an operation?

(I don't feel strongly about the atomicity issue, but I thought there
might be people who did, perhaps including my future self.)

  [snip]
> mime types have come up enough times that I think I'm going to add a
> field for them; anybody that doesn't want shouldn't need to implement
> them though.
> 
> (I know of at least one filesystem that does know the mime-type
> information though.)

Which one is that, out of interest?