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 , 7 weeks ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 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 , 7 weeks ago
Priority: | normal → critical |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
comment:4 by , 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://
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.