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

[Alkis Georgopoulos]

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.

[Tim Kosse]

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.

[Alkis Georgopoulos]

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.

[Tim Kosse]

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

[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.

[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.

[bantu]

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

[mafufz]

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.

[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

[taur]

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?).

[mafufz]

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.

[Zoddo]

Incrasing priority because this function causes irreversible data loss.

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

[Tim Kosse]

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

[Zoddo]

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

[Zoddo]

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

[Zoddo]

Why you don't reply?

[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).

[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.

[Keitsu]

deleted comment

[Stephen Witherden]

Hi, all, I'd just like to add my vote for changing this default setting or even removing this feature altogether. I spent a couple days trying to figure out what was wrong with my own FTP code for archiving data as extension-less files to FTP, only to find the corruption was being done by FileZilla.

FileZilla is awesome, especially for a free tool. This feature does need to be better advertised though. I am sure that if I spent days scratching my head, many others have as well. Silently mangling files is pretty uncool.

[kalzd]

Using version 3.67.1 of FileZilla and it still modifies files by default. I wasn't expecting this is the default behavior. Who would ever want the files modified during file transfer?
Please don't modify files by default.