mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Latorre <dvl...@gmail.com>
Subject Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
Date Wed, 27 May 2009 22:13:20 GMT
2009/5/27 Niklas Gustavsson <niklas@protocol7.com>:
> On Wed, May 27, 2009 at 3:07 PM, David Latorre <dvlato@gmail.com> wrote:
>> I added a fix and some tests but ToNetASCIIOutputStream in
>> commons-util will always replace to \r\n so I'm uploading a modified
>> version. With this fix ascii mode should not eat line separators
>> anymore.
>
> Thanks! Looking into the fix I'm not sure we should print EOL on \r.
> Since \r is not the canonical line ending in the RFC, I think we
> should rather print \r as it is in the stream. What do you think?

I don't really know if \r has other users than being part of the New
Line sequence. I guess \r could take us back to the beginning of the
line ... but it doesn't make much sense in a file.

My reasons to leave \r as the character substituted by EOL are 1)
Because it was previously written in that way.   2) Mac OS 9 and
before had \r as the new line separator, so if the line endings of a
Mac OS 9 text file weren't transformed to \r\n and we were  ignoring
\r , we would swallow the new line again. On the other hand, if we
write the \r  character,  we cannot transform to Unix line endings
which have no \r...

So, I'm sure there are other options and they might be more
performant, but this solution seems to work in several situations
which are usually not supported and the code is fairly easy to
understand ...

Of course, for me , the best solution is to entirely remove the ASCII
mode  from the RFC :-D






>
> /niklas
>

Mime
View raw message