Subject: RE: solving the SFTP text mode issue

From: Darren Moffat <[email-masked]>
Date: Fri, 10 May 2002 12:49:55 -0700 (PDT)

>> What if we provide an SFTP command that the client could
>> execute to learn the line separator on the server machine?
>
>I know that this doesn't take care of record-based text file formats, but it
>does take care of Unix, Windows, and Mac, which is much better than nothing,
>and is probably what most people want, anyway.

I'm not sure it does actually solve the probelm for MacOS X unless it is
done on a per file basis.  On MacOS X the line separator could be either
UNIX style or Mac style depending on the creator of the file.  I'm no
Mac expert but I believe that information is easy to find out.

--
Darren J Moffat

---

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 10 May 2002 13:59:45 -0600

> Mac expert but I believe that information is easy to find out.

It is easy to find out the creator, but I'm not
so sure finding out what line termination the
creator is using is easy.

Last time I worked on the Mac, the creator
attribute of a file was a four byte field,
set to things like 'TEXT' or 'WRTE' or
whatever.

But that doesn't really say anything about
what newline convention the creator is using.

I don't think the MacOS X problem can be solved even
on the server side, because while the server can
determine who create the file (or at list a 4 byte
tag representing the creator), it can't know what the
creator uses for new-line.  I'd love to be wrong
on this, and learn that MaxOS X stores an attribute
that tells what the newline convention is.

I'd also be surprised if unix apps living in the
MaxOS X world maintain creator information, or,
if the mythical 'newline' file attribute exists,
that they maintain it.

- Joseph

---

From: [email-masked] (Albert Lunde)
Date: Fri, 10 May 2002 16:49:06 CDT

> that tells what the newline convention is.

As far as I know, there's no global convention for storing
end-of-line representation. A counter-examples of sorts, is
BBedit, which will default to any of the big-three end-of-line
representations, as configured, and optionally store that
fact in an application-specific resource.

Ugly hacks might be required to determine end-of-line representation
(or character encoding, or text vs. binary files) in the general case.

(It seems to be that this is one more reason to keep any ugly hacks
on the platform where the problem exists, (rather put lots of varients
into a wire protocol for a text mode) and to make support for a text mode 
transfer optional.)

--
    Albert Lunde          [email-masked] (new address)
                          [email-masked] (old address)