Opened 7 weeks ago

Last modified 7 weeks ago

#13225 reopened Bug report

! Uploading / downloading 350byte file with no extension becomes 347-354byte ! (FZ v.3.68.1 is changing it)

Reported by: PizzaProgram Owned by:
Priority: critical Component: FileZilla Client
Keywords: modifying, bug, CRLF, char inserting Cc: PizzaProgram
Component version: 3.68.1 Operating system type: Windows
Operating system version: 10+11

Description

Both uploading and downloading files via SFTP has disastrous results.

If the file I'm uploading:

  • has no file-extension, and
  • contains characters like LF (line feed), EXT, ...

FZ is modifying it, by adding a CR chars before those chars!

It happens both on :

  • Win11 latest with built-in virus checker and
  • Win10 stripped (no AV, no Firewall)

I've tested it with latest Total Commander SFTP, and everything is fine.

Only FileZilla is modifying the file while transferring it, for example to this FTP server: ftps://deni9.deninet.hu
(Old Filezilla 0.9.60 beta server can receive it fine with both programs.)

If I rename the file before transferring it to:

test.dat
FZ is handling it fine in both ways.

PS: Actually I'm shocked. I've always thought FZ is the etalon of FTP transfers. Recommended it to everyone since 20+ years.

Change History (4)

comment:1 by Tim Kosse, 7 weeks ago

Resolution: worksforme
Status: newclosed

You mentioned SFTP, but this has nothing to do with SFTP.

FTP has a data type concept. What you see is line ending conversion due to transferring the file with the ASCII data type. Note that since Windows and FTP share the same line ending format (CRLF pairs) for text files, FileZilla isn't even changing the data. The modification in this case is being performed by the remote server, which appears to be running on a Unix-like system, which uses LF line endings.

See https://wiki.filezilla-project.org/Data_Type for more information. You can configure in FileZilla's settings dialog, which data type to use for FTP transfers, and in case of auto mode, select which types of files, based on extension, use which mode.

comment:2 by PizzaProgram, 7 weeks ago

... let's see, if I understand it right:

You are saying:

  • it is the "servers fault", and
  • my setup is wrong

Than how is it possible, that if I do the same transfer with Total Commander, everything works fine with "default setup" ?

  • while TC is not specialized to handle FTP transfers,
  • but FZ does?

Basically:

  • You know about, that FTP standard has this big flaw, if using ANSI transfer for years.
  • You know about, that using "binary" type of transfer would eliminate this problem, because it always works, no matter what type of file getting transferred, and no matter what OS differences there are.

Yet, the default setting of FZ. is the not-always-working = risky one?

Really? :headbang:

From an other point of view...

Why is 'Automatic' transfer type not always recognising the right one?

Is it not possible, that there is a bug in FZ. ? Something like:

  • no file extension => should be Binary transfer!

(because it works fine, if I change the file extension to: .dat)

If you could point me to the right line of the code, at which this "automatic decision" is happening, maybe I can see something fishy.
Until than:

SET DEFAULT TO BINARY PLEASE!

comment:3 by PizzaProgram, 7 weeks ago

Priority: normalcritical
Resolution: worksforme
Status: closedreopened

comment:4 by PizzaProgram, 7 weeks ago

From my point of view,

(and I've talked to 3 other programmers during last 16 hours, and they all agree,)

  • if FZ is not able to transfer files to/from an FTP server
  • and files getting randomly modified/scrambled


than this is clearly a critical bug.

So I've reopened it and changed to priority.

If you disagree, please put a warning to the top of the program with 72 font size and red color://

If you are using default setup of this program, your files might get modified during transfer, so check them one by one.

Note: See TracTickets for help on using tickets.