ASCII transfer bug (hard to debug)

Hi all,

I think I found a bug in the ASCII file transfer converter : It converts EOL in files by blocks (class FileBuffer)

when using SFTP protocol, my Winscp transfer 262148 bytes and convert them, then transfer 262148 bytes and convert them etc.

The problem I have is the following :

- I connect FROM a windows server (whose EOL is CR+LF)
- I connect TO a linux server (whos EOL is LF)
- I GET a file
- the file is a .txt who is using DOS EOL (CR+LF)

The FileBuffer::convert functions is smart enough to NOT add one more CR to the existing CR+LF

However, since it converts LF to CR+LF for a BLOCK at a time, I have a RARE CASE when the 262148 block ends by a CR :

the next block STARTS BY A LF !! So the "convert" functions adds a CR to it !

So in this very rare case, the ascii converter transform ONE CR+LF into CR+CR+LF !
and that happen one time in the middle of my file ! ...

the convert function should remember if the latest block ended by CR (or LF for MAC EOL convertion)

if you need more explanation or a test file, don't hesitate, I know how to reproduce it

(tested on version 4.3.2)

regards,

Benjamin Sonntag

I have sent you an email with development version of WinSCP. Please respond.

Hi,

I juste tested the .zip you sent me, but it looks like we have exactly the same bug,

I will double-check it using a more thorough testing (I tested it very quickly yesterday...)

more to come soon

and thanks A LOT for this so quick answer :)

regards,

OK, let me know.

Anything new?

Hello Martin.

I believe I am seeing the same issue, which seems easy to reproduce with a particular text (.txt) file I have, downloading it with either WinSCP 4.3.2 and 4.3.3. The file is a DOS line terminated file (CRLF) starting as 25,284 bytes. I uploaded it (using 4.3.2) over SFTP to a Linux box in 'binary' mode, and the file was fine there, still 25,284 bytes, same md5sum. My colleague, using 4.3.3, in 'automatic' mode, downloaded it to his PC, and it was 25,285 bytes, and a quick ExamDiffPro on it and the original showed an extra CR byte had made its way into the file, not at the end.

To test, I repeated the steps, this time uploading the original file with 4.2.8 in 'binary' mode on a spare PC, and downloaded with my PC - 4.3.2 now in 'automatic' mode - and it still happened.

Happy to send the file to you privately for you to have a go.

Andy

For completeness, tried 4.3.5, same behaviour.

cheers Andy

Please email me the file. Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

martin wrote:

Please email me the file. Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

You will find my address (if you log in) in my forum profile.

Done.

Thanks, Andy

We've experienced this same bug last week in version 4.2.9 and I was wondering if this bug is already fixed or if there is Tracker ID for this bug.

WieMie wrote:

We've experienced this same bug last week in version 4.2.9 and I was wondering if this bug is already fixed or if there is Tracker ID for this bug.

Can you send me an email, so I can send you back a debug version of WinSCP to track the problem? Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

martin wrote:

WieMie wrote:

...

Can you send me an email, so I can send you back a debug version of WinSCP to track the problem? Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

You will find my address (if you log in) in my forum profile.

I've sent you a mail, unfortunately I have no posibility to install a debug-version in our environment. I'd like to ask our IT-departement to install a newer version of WinSCP if this bug is fixed in it. I'd expect a bug to have been reported in https://winscp.net/tracker/ (or is this something we should report there?)

WieMie wrote:

I've sent you a mail, unfortunately I have no posibility to install a debug-version in our environment. I'd like to ask our IT-departement to install a newer version of WinSCP if this bug is fixed in it. I'd expect a bug to have been reported in https://winscp.net/tracker/ (or is this something we should report there?)

This was not fixed, because I cannot reproduce the problem. So I need someone to test it with the debug version.

This seems a quite rare bug, but I experience it myself now.
Please tell me how I can help. Where do I get the debug version?

Regards
at3m

at3mlos wrote:

This seems a quite rare bug, but I experience it myself now.
Please tell me how I can help. Where do I get the debug version?

Thanks for your report.
I have sent you an email with a development version of WinSCP to address you have used to register on this forum.

Thanks for the reply Prikryl,

just had a few test with the dev Version but i still have the same Problem.

Basically I'm saving the file as 'Unix-Format' (tried multiple editors in Windows) but when I open it again it is recognized as Windows-Format.

Tried also some other tools (ex. in-build sftp from notepad++ and the problem doesn't occur.

In case You need detaild information please let me know.

Best regards,
at3mlos

post edit: although the file is open in 'windows-format' after a save as 'unix-format' the file rezides on the unix file system as 'unix-format'

at3mlos wrote:

Basically I'm saving the file as 'Unix-Format' (tried multiple editors in Windows) but when I open it again it is recognized as Windows-Format.

OK, so it does not look like the issue this thread is about, right?
What transfer mode are you using? Make sure you use binary.
Are you opening the file directly from WinSCP or externally?

This bug has been added to the tracker:
https://winscp.net/tracker/845