Ticket #4235 (closed Bug report: fixed)

Opened 6 years ago

Last modified 11 months ago

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

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

Description

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.

Attachments

footer-bg.gif Download (192 bytes) - added by Slavon 2 months ago.
 Ron Webb

Change History

Changed 6 years ago by codesquid

  • priority changed from critical to normal
  • status changed from new to closed
  • resolution set to rejected

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.

Changed 6 years ago by alkis

  • cc alkisg@… added
  • status changed from closed to reopened
  • resolution rejected deleted
  • priority changed from normal to critical

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.

Changed 6 years ago by codesquid

  • priority changed from critical to normal

"/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.

Changed 6 years ago by alkis

"/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.

Changed 6 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.

Changed 5 years ago by bantu

  • cc bantu@… added
  • priority changed from normal to high

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

Changed 2 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.

Changed 2 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

Changed 16 months 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?).

Changed 14 months ago by couponcode

Changed 14 months ago by couponcode

  • status changed from reopened to closed
  • resolution set to fixed

Changed 2 months ago by Slavon

Note: See TracTickets for help on using tickets.