Opened 10 years ago

Last modified 9 months ago

#4235 reopened Bug report

"Treat files without extension as ASCII file" should be unchecked by default

Reported by: Alkis Georgopoulos Owned by:
Priority: high Component: FileZilla Client
Keywords: data-corruption Cc: alkisg@…, bantu@…, mafufz, taur, zoddo@…
Component version: Operating system type:
Operating system version:

Description (last modified by Tim Kosse)

With this option checked by default,

  • Copying C:\NTLDR fails because it's copied as ASCII
  • Copying /bin/ls fails
  • Backing up a CMS that encrypts the filenames of attached files (=>with no extension) fails

ASCII convertion is file modification.
Files without extension are of unknown type.
Modifying files of unknown type is really something that shouldn't be default behavior.

I'm reporting this bug after having ~2000 corrupted files because of it. And I discovered that the files were corrupted after a week, so even my backup is corrupted.
ASCII convertion for binary files corrupts them irreversibly, please don't do it by default.

Change History (19)

comment:1 Changed 10 years ago by Tim Kosse

Priority: criticalnormal
Resolution: rejected
Status: newclosed

I cannot remember when I last transferred an executable. All the extensionless files I transfer really are text files.

That's why there is an option so that you can chose how to treat extensionless files.

Remark: DO NOT mark tickets as critical which are not (remotely exploitable) security vulnerabilities.

comment:2 Changed 10 years ago by Alkis Georgopoulos

Cc: alkisg@… added
Priority: normalcritical
Resolution: rejected
Status: closedreopened

Sorry for the late response, I didn't get the notification email.

Remark: DO NOT mark tickets as critical which are not (remotely exploitable) security vulnerabilities.

I can't think of anything more critical than corrupted binary files.

Yes, it is a possible security vulnerability.
I'm sure there are hundreds of "harmless" 0x0D 0x0A assembly instruction combinations that can become harmful if the 0x0D is removed (or added). I can make a test case in assembly, if that'll convince you, but it should be obvious.

And, of course, not only malicious processes could be ran; corrupted binary files could do whatever, even permanently damage the file system.

I cannot remember when I last transferred an executable. All the extensionless files I transfer really are text files.

I guess you've never worked on anything other than Windows, am I right?
Please, Tim got to all this trouble to reprogram filezilla with wxWidgets to make it cross platform, don't throw it out of the window.
Do an "ls /bin" on a *nix system to see how many of the binaries there have an extension.

comment:3 Changed 10 years ago by Tim Kosse

Priority: criticalnormal

"/bin" and other directories for executables are managed by the system's package manager, ordinary users shouldn't even copy these files.

I cannot remember the last time I transferred a non-text extensionless file, and I do use non-Windows systems.

We obviously disagree on how extensionless files should be transferred by default. For that very reason there's an option in the settings dialog.

comment:4 Changed 10 years ago by Alkis Georgopoulos

"/bin" and other directories for executables are managed by the system's package manager, ordinary users shouldn't even copy these files.

Erm, the package manager isn't the only way to install executables in *nix, one may compile them from source or even download binaries or self extracting archives via ftp. And people also have binaries under their home directories, e.g. in ~/bin, which they usually want to backup, with, say, filezilla. Also, many data files (non-executables) exist with no file extension - like some database files. Filezilla can also be used to clone an entire Linux installation, or to backup a CMS like SMF which renames the attachments and saves them without extensions for encrypting reasons.

We obviously disagree on how extensionless files should be transferred by default. For that very reason there's an option in the settings dialog.

Well, as we grow older memory stops serving us well; I don't want to risk having corrupted files again (or worse!) in the very probable case that I'll forget to uncheck this option in a new filezilla installation. I'll feel safer if I just stop using filezilla.

Thanks for your time, I loved using filezilla these last years until this horrible incident.

comment:5 Changed 9 years ago by mariush

I would personally (also) vote for assuming all files are BINARY, even text files.
There are cases where files must be uploaded exactly as they're stored because something else relies on them.

For example, let's say you have the following files:

My movie.avi
Readme.txt

You create a .torrent file on your local computer and upload the files to a dedicated server, so that server will upload data to users.

By definition, when a torrent is made, the program splits the whole bunch of files into chunks of data (the minimum being 256KB) and generates a hash for each chunk.

When the torrent file is loaded on the dedicated server, the program seeding the files would check if data is complete and will detect the last chunk as corrupted, because readme.txt was transferred in ASCII, so obviously it's different. But it's confusing, because everything works fine on the local computer and no matter how many times user will recreate the torrent file, it will still be incomplete.

Please don't jump to conclusions and say something like "filezilla is not for pirated content", I'm actually working with real, legal content, uploading things to CDN's and distribution servers.

If everything will work fine for any file extension with BINARY, it doesn't make sense (at least for me) to leave a default ASCII for text files. I'd prefer 100% compatibility with everything.

comment:6 Changed 8 years ago by bantu

Cc: bantu@… added
Priority: normalhigh

I agree with the initial poster that the checkbox should be unchecked by default and files without extension should be transferred 'as is'.

I would also say that ASCII mode should be disabled completely by default and all files should be transferred as they are, since that's what FTP is IMO all about today. Hashing the files on both sides should (for obvious reasons) always have the same result, as has been already said. Transferring files in ASCII mode can result in unnecessary (preventable) data corruption. ASCII mode should therefore only be enabled when necessary (which is almost likely only rarely the case). This should protect your users from data loss.

Increasing priority because of potential data loss[0].

Thanks,
bantu - phpBB developer

[0] http://www.phpbb.com/community/search.php?keywords=filezilla+attachment

comment:7 Changed 6 years ago by mafufz

Cc: mafufz added
Keywords: data-corruption added

I cannot believe this ticket is still open. This is a ridiculously easy change without that, without doubt, thousands of hours of time of this program's users have been wasted over the past few years.

Please fix this ASAP. If you want I can even do it myself if you want, though I am not familiar with the configuration update module for existing installations.

comment:8 Changed 6 years ago by mafufz

If this is of any help, have a look at this question and the linked questions: http://stackoverflow.com/questions/554960/how-can-i-stop-filezilla-changing-my-linebreaks

comment:9 Changed 5 years ago by taur

Cc: taur added

Bump
5 years now, this is ridiculous,
this "feature" adds extra CR to my already CRLF encoded ascii-files for no apparent reason (added server-side maybe?).

comment:10 Changed 5 years ago by couponcode

Resolution: fixed
Status: reopenedclosed

comment:12 Changed 3 years ago by mafufz

Resolution: fixed
Status: closedreopened

This ticket was closed by a user who also posted a spam link. I suspect it is save to assume this ticket should not have been closed, so I am reopening it.

comment:13 in reply to:  description Changed 3 years ago by Zoddo

Cc: zoddo@… added
Priority: highcritical

Incrasing priority because this function causes data loss.

It's totally inadmissible that this ticket is still open after 7 years!!

Version 0, edited 3 years ago by Zoddo (next)

comment:14 Changed 3 years ago by Tim Kosse

Description: modified (diff)
Priority: criticalnormal

It does not cause data loss. The source file is not being overwritten.

comment:15 in reply to:  14 ; Changed 3 years ago by Zoddo

Priority: normalhigh

Replying to codesquid:

It does not cause data loss. The source file is not being overwritten.

Some users uses filezilla to transfer a website from an hosting to an another hosting.

When these users realize that some file have been corrupted, their old hosting has been closed so they can't get the original file and these files are definitely lost.

Other example, users download their hosting space to make a backup. When a problems occurs and that they try to reupload their backup, he realizes that their backup is corrupted.

Disable this option by default takes few seconds and can avoid many problems...

comment:16 Changed 3 years ago by Zoddo

What is the real reason why you don't want to change this setting by default?

comment:17 Changed 3 years ago by Zoddo

Why you don't reply?

comment:18 Changed 16 months ago by Kurt McKee

Triage suggestion

It appears there's been no real movement on this ticket for many years. The ASCII/binary debate could go on indefinitely. In the age of smart code editors and version control systems that can handle CRLF/CR/LF differences, the default behavior should definitely be to always transfer in binary mode. However. While defaulting to ASCII mode corrupts binary files irretrievably and is surely very infuriating (like WinZip's stupid, stupid miscellaneous option to do the same thing when extracting .tar.gz files), this is still a configurable option.

I suggest closing this ticket as "wontfix" (but will hold out hope that the default behavior is changed so that transfers default to binary mode).

comment:19 Changed 15 months ago by cristianmad

https://www.hanselman.com/blog/13HoursDebuggingASegmentationFaultInNETCoreOnRaspberryPiAndTheSolutionWas.aspx :)

Why not simply defaulting to Binary?

I agree with some of the previous comments suggesting to simply close the issue if there are no plans of addressing it.

Last edited 15 months ago by cristianmad (previous) (diff)

comment:20 in reply to:  15 Changed 9 months ago by Keitsu

deleted comment

Last edited 9 months ago by Keitsu (previous) (diff)
Note: See TracTickets for help on using tickets.