[Bug TC6.01] lineends in text transfer mode

[413x]

i guess i've found some bug, though i'm not 100% sure about all situations.

if i download or view a text-file from a ftp-server using _binary mode_ everything is going fine. but if i download/view the same file using _text mode_ (as intended to convert the lineends between different os) the lineends get messed up. this also happens in automatic mode.

some examples done in text mode:
(server -> local)

LF -> CR LF (ok)
LF LF -> CR LF CR LF (ok)
CR -> CR
CR LF CR LF -> CR CR LF CR CR LF (not ok)

[icfu]

Where do the CRs in the server file come from? Makes no sense.
Either it is stored in UNIX-format (LF only) or it is not.

TC converts all <LF> instances to <CR><LF> so it's all ok.
My conclusion, the text file is either not a clean UNIX text file or it is corrupted.

Icfu

[413x]

Where do the CRs in the server file come from? Makes no sense.
Either it is stored in UNIX-format (LF only) or it is not.

TC converts all <LF> instances to <CR><LF> so it's all ok.
My conclusion, the text file is either not a clean UNIX text file or it is corrupted.

Icfu

i'm a programmer and also have to do a lot of scripting/webdesign for different companies and most of the time the files on the server have different lineends. some even have inconsistent endings inbetween the same file. it seems there are a lot of people uploading their windows text files in binary mode, so there are CR+LF on unix servers. i know this is bad behaviour but i can't change this and i expect correct lineends from a textmode download. cr+lf should be handled correct by the total commander conversion function. summary: cr+lf is not 2 times lf!! but it is very annoying to have extra lines between every normal line.

[Clo]

2413x
Hi!
Could be that text-file a MAC text-file?
Following your last example: CR -> CR

In that case, you have <CR> (#13) character only; I don't know if TC does the conversion...
Kind regards,
Clo

[413x]

2413x
Hi!
Could be that text-file a MAC text-file?
Following your last example: CR -> CR

In that case, you have <CR> (#13) character only; I don't know if TC does the conversion...
Kind regards,
Clo

sorry, i forgot to mention, that i tried a few different files.

[icfu]

cr+lf is not 2 times lf!!

You have written that:
CR LF CR LF -> CR CR LF CR CR LF (not ok)

Each LF instance is converted to CR/LF.

When files are uploaded one time in text mode and the other time resumed in binary mode file endings are corrupted, that's pretty normal.

How should TC handle these files in your opinion? If I understand you right you want CR/LF to be ignored then? Not sure if this is a good idea.

Icfu

[413x]

cr+lf is not 2 times lf!!

How should TC handle these files in your opinion? If I understand you right you want CR/LF to be ignored then? Not sure if this is a good idea.

Icfu

quick idea: maybe some optional warning if download mode is text/auto and the conversion routine detects CR+LF in a file.

plus an optional handling to _not_ convert CR+LF to CR+CR+LF and let these untouched.. i don't think i'm the only one having problems with the standard behaviour since a lot of people ignore (or don't care) about such standards but do web design anyways..

[413x]

..maybe c.ghisler can tell us his opinion about this?

[ghisler(Author)]

The FTP client (here: Total Commander) doesn't do the conversion to CRLF, it's done by the FTP server when it is sent the command MODE A. So TC is innocent - your ftp server does the conversion! Apparently you uploaded some Windows files in binary mode and then downloaded them in Text mode. Solution: Re-upload them in Text mode, and then get them in Binary mode.

[413x]

The FTP client (here: Total Commander) doesn't do the conversion to CRLF, it's done by the FTP server when it is sent the command MODE A. So TC is innocent - your ftp server does the conversion! Apparently you uploaded some Windows files in binary mode and then downloaded them in Text mode. Solution: Re-upload them in Text mode, and then get them in Binary mode.

i see! many thanks for your explanation. i apologize myself for blaming TC..

the origin of this problem is caused by some of my customers who upload their files in binary mode (sadly most of them don't know (about) the difference) and it's very cumbersome to verify all the different (and lineend-varying) files. i guess from now on, if in doubt, i'll download them in binary mode..