Re: Text file type hint proposal for filexfer

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

Jacob Nevins wrote:
> 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.)

All right; I'll do that.

> > 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.
[snip]

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

Well, in theory, a VMS server would not set 
SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT and hence the client
would know that it can't send the attribute.

However, unless someone speaks up at least moderately
in favor of the atomicity issue, I think I'm going to
drop that and forbid both flags during any kind of
setstat operation.

(Which I'd prefer to do rather than have some kind of poorly
defined result when setting the flags.)

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

I think if we decide to try and address atomicity issues that
is a fine idea.  I will probably go that route.

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

I believe BeFS (from BeOS) supported mime types as it's
native typing mechanism.

There is at least a small movement creating an open source clone,
so it isn't completely dead.

A MS Windows based server that wanted to provide the information
could query the registry from the file extension as well.

(I doubt we will, but it is possible, and someone else might decide
to do it.)

- Joseph