Opened 12 years ago

Closed 6 years ago

#7791 closed Feature request (duplicate)

Option to disable confirmation prompts on remote editing save/upload

Reported by: Andrew Owned by:
Priority: low Component: FileZilla Client
Keywords: automatic upload, external edit Cc: ciantic@…
Component version: Operating system type: Windows
Operating system version: All Operating Systems

Description (last modified by Tim Kosse)

Please read the whole thing before you disregard it yet again. I am posting this as a new issue, even though it is a very old issue, because the alternative would be to reopen one or all of these issues:
And on the forums:

I have read every single post of every thread listed above, and I fully understand the technical issues raised -- really, I do. Codesquid/botg, you seem to regard this as a foolish request for a minor feature that would cause major problems. But the risk is on the extreme fringe -- a vanishingly small percentage of the FileZilla userbase whose presumed stupidity somehow outweighs the NEEDS of the vast majority who only edit small text files.

The confirmation prompt is not a minor annoyance, it's a major and unnecessary BOTTLENECK IN OUR WORKFLOW. I sometimes save/upload/refresh SEVERAL TIMES PER MINUTE, often with several files at once. That prompt absolutely kills my productivity, but the only way I can get rid of it is with a hackish AutoHotkey workaround or to patch the source and recompile??? That's just ridiculous, and here's a list of other FileZilla users who have already taken the time to post on this ticketing system to express interest in this simple but crucial capability:


And on the FileZilla forums:

Ray Yates

Please consider that list a petition.

Among all these tickets and forum threads, I found only ONE user who expressed full agreement with the current policy of requiring a prompt on every save/upload with no available option to bypass it:

(...boco? He hasn't publicly disagreed with your stated position, but he has reluctantly admitted that the current situation is a real problem.)

The rest of us are not simply a vocal minority, we're the vast majority of your users, and we're a lot smarter than you give us credit for. We're not asking you to endanger the integrity of those fringe users' data, we're only asking you to give us the opportunity to gain an ENORMOUS improvement in the efficiency of our workflow through a simple NON-DEFAULT option with a very clear warning/disclaimer right in the GUI. There's NOTHING UNSAFE about that!!! It's not the developer's fault if grandma formats the root partition, and it's no reason to take away the format command just because somebody might accidentally destroy their data. Some amount of hand-holding safeguards are appropriate, but ultimately, you just can't save stupid users from themselves -- certainly not at the expense of the great majority who are unaffected by the risk in the first place.

So here's an original suggestion to legitimize this post as a new issue: whitelist and/or blacklist by filetype and/or external editor program. That's clear enough, right? Whitelisting would only allow bypassing the prompt on filetypes or editors known to be safe. Blacklisting would only forbid bypassing the prompt on filetypes or editors known to be at risk. The community could maintain the list(s) so you don't have to deal with the tedious details. Of course, it's easier to just have a bit more faith in the intelligence of your users -- or a healthy disregard for their self-caused problems -- but if you're adamant on protecting them from their own persistent ignorance, this is a solid solution. And please don't tell me it's a "technical impossibility." ;)

Seriously, though, thanks for all your hard work over the years. FileZilla is truly wonderful and very appreciated.

  • Andrew Lundin

Change History (14)

comment:1 by Jari Pennanen, 11 years ago

Cc: ciantic@… added

I checked back to see if this was fixed, been using WinSCP because it has automatic directory synchronization without dialogs. Latest version of WinSCP is (for the moment at least) buggy, I decided to look back if FileZilla has gotten around to fix this. And found this!

What a wonderful petition, yet has anyone building FileZilla bothered to answer? Not a one! Down with the regime, hopefully soon someone is annoyed enough to fork :)

comment:2 by Jari Pennanen, 11 years ago

I'd like to point out that there are many who don't even use FileZilla cause this feature is not implemented, and potentially would like to use it when it gets implemented.

See for example this: StackOverflow QA about similar feature wanted for Mac OSX.

comment:3 by Jari Pennanen, 11 years ago

(Sorry my link is pointing to my answer in StackOverflow, but I was supposed to link to the parent Question which asks for this kind of feature)

comment:4 by sgrossberndt, 11 years ago

Please add that option!

comment:5 by haystack, 9 years ago

After using filezilla for years, i've changed to WinSCP because of it.
Then i rollback because of WinSCP occasionally crashes.
The main drawback of filezilla never dies.

comment:6 by Alexander Schuch, 9 years ago

Keywords: automatic upload external edit added
Operating system type: Other

This is a summary of related issues, still this is a duplicate of #2914.

comment:7 by xblondel, 9 years ago

Operating system type: Windows

+1 as petitionner , though I don't like this word.
I need this functionnality of autoupload on change.
I am now using winSCP from a few months, waiting for this functionnality to go back to Filezilla

comment:8 by David Tanner, 9 years ago

I find it hard to believe that the developers are sticking to the opinion that this will cause mass data corruption. I have been using winscp to work on remote files, and only am trying out FileZilla because winscp keeps disconnecting on me. The prompt is a major impediment to my workflow. I am afraid I cannot use this tool for that reason.

comment:9 by Bart Nijs, 9 years ago

+1 for me to. I haven't posted about this in any thread but I have read every thread about this issue. Hoping to find a solution.
Like the original poster I appreciate the hard work, but the fact that for every file I save I have to confirm that I want to re-upload it is really annoying and time consuming.

comment:10 by exa, 9 years ago

This has been requested for 6 years (possibly more?)
It has been done in a number of other ftp clients.
It really shouldn't be the hardest thing to implement. Heck, the current prompt, is atleast as unsafe, as any automated procedure would be.
Except. It requires one to (windows) alt+tab, enter, alt+tab x2, in order to get from editor -> FZ prompt -> whatever you are editing.
That is silly. It's really just a couple of seconds, for each edit. But that in itself is a pain.

I really see no sensibel reason, as to why the prompt should be there. Even on the trac, there has been several solutions presented, which all have been ignored.

Six years should be more than sufficient, to come up with a permanent solution, to replace something, that clearly (!I hope), wasn't meant to be THE SOLUTION, for a problem.

It would quickly save me a lot of time. I estimate, that i spent around a couple of minutes a day, on these prompts (a guess is 5-10 minutes). Multiply that, with the amount of FZ users, per day. The number, representing time, should be reason enough, to push this feature to the top of any pile.

comment:11 by Stephen Akins, 9 years ago

I would also like to see this option. I have used other FTP clients that allow dialogless auto transfer of edited files and the difference it can make to one's workflow should not be underestimated. This is a major issue.

comment:12 by ozoned, 9 years ago

I would like to note that the only time the save dialog appears is when I save the file I'm editing. If the developers consider non-user initiated changes a liability to a file's integrity, shouldn't this dialog be appearing far more often?

In terms of workflow, the dialog is a major bottleneck, especially if my network is congested. Upon saving I have to stop what I'm doing, wait for the dialog, then the upload, then review my changes.

comment:13 by LGosselin, 7 years ago

Here's another vote for the feature, although I'm skeptical that after a decade of this feature being requested, it will make a difference. Filezilla would be a better program for many people, this is such a common use case.

I'd like to point out that the reason given for not implementing the feature is invalid because there is *zero* additional risk of file corruption that didn't already exist before this feature was implemented.

Firstly, with FTP, there is always a chance that every file transfer could end prematurely due to network or even OS conditions beyond our control. I don't deny this will leave the file in an incomplete state, but the fact is this type of corruption is not something new arising out of this feature, it's always going to be a possibility regardless of if an auto-sync feature is available or not.

Second of all, uploading an incomplete file because the text editor has not finished writing it does not cause any new kinds of corruption either. The exact same race condition already happens if we remove ftp and filezilla as an intermediary by running the same file editor locally. There is absolutely nothing special about filezilla in this context, it could just as easily be Apache or some other daemon reading a config file. If the editor did not lock the file it's writing, then it was *already* a race condition to begin with and not something caused by filezilla auto-syncing. If the editor does lock the file it's writing, then there is no race condition locally or with auto-sync. In other words, auto-sync doesn't cause a race condition, it merely exposes an existing one over the network.

So the assertion that auto-syncing locally edited files across FTP causes corruption has zero merit. And in the event that filezilla attempts to upload a file before the text editor as completed writing it, the absolute worst case scenario is that filezilla automatically uploads the changes again. The majority of people using this feature would find it not only acceptable but also desirable. Anyone not wanting filezilla to do this could simply not click on the button that enables it. Everyone would be happy, so it really strikes me as odd that developers don't want this problem solved.

Whatever the reason for not implementing the features, let's at least put the "corruption" excuse to rest, since the reasoning there is invalid.

comment:14 by Tim Kosse, 6 years ago

Description: modified (diff)
Priority: criticallow
Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.