#9302 closed Bug report (wontfix)
Filezilla damages the binary file it transfers when the file has no extension
| Reported by: | yurivict | Owned by: | |
|---|---|---|---|
| Priority: | low | Component: | FileZilla Client |
| Keywords: | Cc: | ||
| Component version: | Operating system type: | BSD | |
| Operating system version: |
Description
I am trying to transfer the binary file from the remote server to my local directory by dragging and dropping it.
The original file has size 1,855,488 bytes, the resulting file has size 1,855,392, as also reported by filezilla itself.
The file is the binary SQLite database.
The transfer log:
Status: Starting download of /public_html/xxx/includes/xxx
Command: PASV
Response: 227 Entering Passive Mode (198,46,81,146,124,133)
Command: RETR webcal
Response: 150-Accepted data connection
Response: 150 1812.0 kbytes to download
Response: 226-File successfully transferred
Response: 226 2.623 seconds (measured here), 0.68 Mbytes per second
Status: File transfer successful, transferred 1,858,120 bytes in 3 seconds
Status: Disconnected from server
File is always transferred with the same discrepancy (subsequent attempts produce the same wrong version).
The file in question didn't have any extension (no periods in its name). There is 'Default transfer type' option in 'Settings' which was set to 'Auto'. When I selected 'Binary' there, the discrepancy disappeared.
Another, smaller, SQLite database (290,816 bytes) was transferred correctly. It had a period in its name, but no recognizable extension.
So I believe that filezilla wrongfully defaults the type of file without extension to 'Ascii'.
When the type of file isn't known, and 'Auto' is selected, it should default to 'Binary'.
version 3.6.0.2
Change History (5)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
As long as notepad.exe, Windows' default text editor, cannot handle Unix-style line endings, this won't be changed.
comment:3 by , 11 years ago
| Priority: | critical → low |
|---|
Changed to low priority as Critical is reserved for critical bugs. This bug is not critical as it cannot be exploited and can furthermore be worked around.
comment:5 by , 11 years ago
I'm using Unix-style systems, and all the extensionless file I ever transfer are text files.
Knowing that my use case is not the only one, I've added an option to make it configurable how extensionless files are being treated.
On the second thought:
Filezilla doesn't need to even guess the file type. No need to ever use 'Ascii' type (as FTP supports). There is no benefit to client in doing 'Ascii'. Just do 'Binary' on all files, remove this option 'Default transfer type' in 'Settings' screen.
It will be simpler, and no loss of functionality.
FTP had this Ascii option added in ancient times, they thought it will be useful, but it turned out to be redundant. Verbatim transfer is sufficient in all practical cases.