Re: Text file type hint proposal for filexfer

[nisse%lysator.liu.se@localhost (Niels Möller)]

Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost> writes:

> It's perhaps tempting to use the IETF's usual content-type notation,
> "MIME types" (RFCs 2045-9 and related standards). However:

I think a MIME content-type makes perfect sense as an extension, but I
agree it shouldn't be in the sftp spec proper. Therefore, I think it
is a little confusing to use the name "CONTENT_TYPE" for the attribute
you propose. Perhaps something like FILE_MODE, OPEN_MODE, FILE_TYPE
might work?

One other observation:

If you have this attribute, *and* there is some way of knowing the
server's line end convention, then it would be possible for a client
to use the following strategy:

Always SFTP_OPEN files in binary mode. Use FSTAT to ask the server if
it's a text or binary file. Next, figure out what are the server's and
the client's native line ending convention. Then convert the file as
it is read.

As far as I can see, this simple scheme will work just right for
servers where your new attribute is fully supported (i.e it is always
correct, and never returns "unknown"). It will of course always fail
on servers on operating systems that

 * differentiate between text and binary files

 * doesn't provide a reliable way for an application, e.g. the sftp
   server, to find out if a given file name refers to a text or binary
   file.

However, I don't see any way to get things right automatically in this
case; there's no reliable information anywhere that says definitely if
the file is text or binary, so it must be guessed, either by the user,
or by the client or by the server. And whenever that guess is wrong,
file corruption can be expected.

Is this problematic case common? To me, it seems so fundamentally
broken that I don't think we should work very hard to try to fix it.

Best regards,
/Niels