Preference option to bypass confirmation for remote edit upload trigger

[Avery Brooks]

I'm using FileZilla v3.2.6.1

It would be nice, in addition to the "Watch Locally Edited Files for Modification And Prompt..." to have an "Upload Automatically" option. This would be a life saver for tedious 'remote' edits and testing.

Side note: i'm a longtime FileZilla fan, used on PC forever, after switching over to OS-X from Windows, I had a brief affair with CuteFTP, but then came back when the OS-X port of FileZilla became available.

[Avery Brooks]

Possibly as 3 radio buttons to replace the current check?

• Don't watch locally edited files.
• Watch locally edited files, and prompt to upload.
• Watch locally edited files, and upload immediately.

[Tim Kosse]

The prompt has to stay. It is impossible to automatically detect when it is safe to upload a file. Without the prompt there would be a high chance to upload a file while some other program is still writing to it, leading to corrupt files. Since almost all users do not understand the implications, the prompt has to stay.

[Avery Brooks]

I have to say I disagree. The default should be the "safest" method for most users. The file changing locally indicates that it has been "saved" by the editor. This can be interpreted as a request to update the remote file. If you are "editing a remote file" it follows that you are intending to overwrite the file when you hit "save" in your editor.

Alternate option, can you expose the structure for saving preferences so that more advanced users can set this option manually?

[Tim Kosse]

Simple case:
Program A begins saving
Program B sees file has changed and starts uploading
Program A continues saving
Program B uploads corrupt file

Complex case:
Program A begins saving
Program B sees file has changed and starts uploading
Program A stops saving because file is opened by other program
Program B uploads corrupt file AND local file is corrupt as well

This does and will happen if there's automatic upload.

[Avery Brooks]

If these two cases cover the full range of possibilities, how do you propose the developers of CuteFTP got around it? I used an equivalent feature in that software daily for around 3 years, doing exactly what you are saying is impossible to do without corruption. I had more issues with corrupt files in MacFUSE.

Also, in the existing situation, the only thing that is preventing corruption you describe from your scenarios is a delay in the user's response that allows enough time for the local write to complete. If the user was able to respond more quickly to the dialogue, there would be the same result. This could be the case easily with an extremely large file. It sounds to me like there is a larger issue under the surface.

[miked]

was working in previously revisions, now inop in:

FileZilla Client

---

Version: 3.3.0.1

Build information:

Compiled for: i586-pc-mingw32msvc
Compiled on: x86_64-unknown-linux-gnu
Build date: 2009-11-15
Compiled with: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.10
GnuTLS: 2.8.3

[miked]

this is a 50/50 call, going to mark this as fixed and re-open a new issue. the original description doesn't match the bug I'm attempting to report by reopening this feature request.

[Mark Slade]

This feature is also available, by default, in SmartFTP (Windows XP Pro SP3). It would appear that this feature is possible, or that these clients are running the same risk. Why not add a grace period between the file changing and the upload action? Something like this:

[1] File change detected. Record timestamp as 'timestamp'.
[2] Wait X seconds.
[3] Is the file's modification time later than 'timestamp'?

Yes --> Record new timestamp as 'timestamp'.

[4] Upload file.

[Mark Slade]

Correction:

[3] Is the file's modification time later than 'timestamp'?

Yes --> Record new timestamp as 'timestamp', and go back to [2].

[Jonathan Bruder]

Please add to Mac OS version. And codesquid, if everyone else in the world is wrong you probably need to consider your perspective. SmartFTP is hardly the only client to do this. Numerous clients on all platforms do this. I haven't a clue what algorithm they use, but figuring that out would be a normal part of discovery, wouldn't it?

[Tim Kosse]

This won't be implemented since it is unsafe in every way.

[miked]

You could make the argument then that allowing file overwrite to occur at all presents the same level of unsafe behavior. However you provide that option when you do drag/drop uploads when there is a file collision.

While I did eject from this issue earlier I am still puzzled with the response - are features now not considered based on some need to protect the use from him/her self? "It is impossible to automatically detect when it is safe to upload a file." I agree, but isn't that the responsibility of the user to put the setting into the desired mode?

In my case I am a single developer supporting a remote site. When I upload a file I am certain that I want to overwrite each time. This is hardly unsafe. Having no way to tell FZ to stop asking me about overwriting a file with each incremental change is beyond ponderous. Having to click the box all day long makes me feel like Desmond in Lost having to punch in the numbers.

[Jonathan Bruder]

Nothing like a little unilateral foot-stomping to prove a point. 70 years of combined web and programming experience in the room I'm sitting in and everyone here was agape when I told them about your responses, codesquid. It's patently stupid that FZ won't find a solution for this problem. EVERY OTHER CLIENT does this. So I guess I'll be going with one of those.

It's a shame; FZ had a chance to be representative of the best class of open tools on the planet. Instead, it represents a ridiculous, closed-minded tool.

[Avery Brooks]

I re-read my earlier posts and I feel the tone perhaps was a little harsh. Just wanted to reiterate here that, I love FileZilla and use it daily. It fills a very important role for me, b/t RSE in Eclipse, and sftp on the command line. Like I said in the original post, I do own a license to CuteFTP, but I use FileZilla because I believe in the importance of open source, especially for ubiquitous tools like this.

[Tim Kosse]

The problem is not with the overwriting, it's with _when_ to perform the transfer. Consider this chain of events:

• User starts remote file editing
• File gets downloaded, external program started
• External program writes to file, and this is important, has not yet finished writing!
• FileZilla sees that file has changed and starts uploading
• Program wants to continue writing but cannot because it's also opened by FileZilla for the transfer

End result: Both the local temporary file as well as the file on the server are corrupt. This is why automatic upload is bad.

Since it's absolutely 100% impossible to detect a safe time for the transfer, FileZilla needs to delegate this responsibility to the user.

[Mark Slade]

I don't do much desktop development so perhaps I'm misguided, but why not acquire a read+write lock on the file before uploading it? If you acquire the write lock, then it's not going to be written to any more. Isn't this precisely the kind of problem file locking exists to prevent?

[Tim Kosse]

Problem is that there are some programs which save files in small chunks and closing the file in between. If you take the lock between two chunks, you get above scenario.
Furthermore, not all filesystems support mandatory locking, especially not if you aren't using Windows.

[Jonathan Bruder]

For your consideration:

1. Get the timestamp of the remote file
2. Store the temporary local file
3. Get the timestamp on the temporary local file
4. Call the editor 
5. Start watching for a timestamp change on the temporary local file*
6. On local timestamp change wait 2 seconds
7. If the local timestamp has changed again
  a) THEN reset the wait timer
  b) ELSE get the remote file timestamp
8. If the timestamp of remote file has changed
  a) THEN prompt user whether to upload
  b) ELSE upload
9. After upload, update stored timestamp of remote file and local file. 

*Excepting the file save behavior you mention, if the timestamp on the temporary local file is changing without user action, then it is the EDITOR that is behaving badly. It is the responsibility of a user to use an editor that does not "touch" files when it shouldn't. If the editor is exhibiting this behavior, it will likely cause a number of other kinds of problems, no matter the file transfer client that's used.

[Jari Pennanen]

This should be fixed, this is a sole reason I still use WinSCP when editing files through SFTP in Windows. It has never failed for me, and I've been using it for years... I think someone in here is a bit overcautious with this thing, sure there is a risk, but how freaking big is it?

By making this as option, and probably adding warning if it feels so great, the enlightened users at least can choose to take this "enormous" risk and ignore the damned prompt...

And BTW, what does the prompt helps anyway? Now when it throws the prompt every time, it becomes a habit of pressing that "Ok" button, and the whole point of prompt is lost anyways, as user does not even check what is going on.

[Chad Huntley]

Every other FTP client has this feature, Filezilla is not better because it lacks this, I don't understand the logic. It's like starting a car company then justifying the reason you do not have wheels is because the driver may potentially run into something.

[Vinicius Massuchetto]

Patch to create an option that bypasses upload confirmation while editing remote files

[Vinicius Massuchetto]

I don't think we're close to an agreement about what to do related to this feature, so it's just FYI: I scratched a simple patch that creates this option. Just ignore if you don't like.

[Redsandro]

Is there library of patched builds somewhere?
I want to see if there's a clever person who applies multiple ignorance bypassing patches in his builds.

[Vinicius Massuchetto]

Replying to Redsandro:

Is there library of patched builds somewhere?
I want to see if there's a clever person who applies multiple ignorance bypassing patches in his builds.

The patch does not mean to be efficient or distributable. It just work fine for me. As I said, ignore if you don't like.
And your consideration is far from polite, too.

[Redsandro]

I like the idea of the patch, thanks.

There's nothing impolite about dedicating a word to influential developers who systematically ignore popular requests for features - that are available in the majority of similar apps - without good reason.

Sometimes some people like to collect patches they think are useful and release builds either for fun or for being helpful. I often use patched builds like this for x264 or blender, for example. I was just looking to see if something similar exists for filezilla, but I guess not.

[Vinicius Massuchetto]

I'm sorry. Some language issues here... =D
Just ignore what I said.

[Tim Kosse]

There's nothing impolite about dedicating a word to influential developer
who systematically ignore popular requests for features [...]
without good reason.

Did you even bother to scroll up, to read and _understand_ the reasons I gave?

[Redsandro]

Yes, and thanks for the patronizing tone.
But like everyone else pointed out, many other FTP clients have similar functions they found out a way to deal with it.
Maybe a user specified delay. Maybe a filesize-proportional delay. I can think of ways.

I especially like some dev's comment to a kid that found another client that has this functionality: "Good luck gambling with your data!" See that's just it. If we - users from the same intelligent species as you - wanted to be unable to set options that can either be good or bad, we'd all get Mac OS X in stead of Linux.

I think we're both right, and I (plus many other users) would really appreciate this as an option, with big red letters recommending to not use it, and a "haha told you so" in the data corruption chapter from the manual if that makes things more clear.

[miked]

Those who are frustrated with the lack of this feature in FZ should check out WinSCP, I made the move to WinSCP a few months back after growing weary of watching the developer do battle with the user community here over a seemingly innocuous feature request that other FTP apps seem to have little trouble implementing.

Can't seem to figure out how to remove myself from the system generated emails on this issue. If someone can let me know how to unsubscribe I'd be very appreciative.

[Vinicius Massuchetto]

Replying to Redsandro:

Yes, and thanks for the patronizing tone.
But like everyone else pointed out, many other FTP clients have similar functions they found out a way to deal with it.
Maybe a user specified delay. Maybe a filesize-proportional delay. I can think of ways.

I especially like some dev's comment to a kid that found another client that has this functionality: "Good luck gambling with your data!" See that's just it. If we - users from the same intelligent species as you - wanted to be unable to set options that can either be good or bad, we'd all get Mac OS X in stead of Linux.

I think we're both right, and I (plus many other users) would really appreciate this as an option, with big red letters recommending to not use it, and a "haha told you so" in the data corruption chapter from the manual if that makes things more clear.

I must say that I completely agree with all of it. IMO, there's still a lack of arguments to justify why not implement this feature.

[Daniel Germer]

Where can I get this option?

It is ridiculous to think that an average user is looking in between file edits and clicking the upload Dialogue.

besides: where can I see that the file is not currently being edited?

If someone is working in an environment where this feature could lead to file-corruptions he will know what he is doing. And he can have a look before he is saving the file.

If not, like in the case of most of us developers, it is tiresome to click "yes" after changing any css property.
Stop this tired discussion and implement the feature please.

[mike henken]

This whole page must be a joke.

I was originally with FileZilla for years.. I love pretty much every aspect of it besides the un-appealing design (I guess ugly is better then bloated).
I moved over to smartftp about 8 months ago because of the horribly irritating and time consuming prompts in filezilla (talked about on this page.).

I am an experienced web developer who makes regular backups of his files, uploads hundreds if not thousands of files a day, and generally edits files from the server to increase efficiency.

I have hundreds of Clients and cannot afford an extra 3 seconds (to switch to filezilla program, move mouse over to accept, move back to editor/browser) each time I want to save a file I am editing straight from the server.

An even more time consuming example:
Often I edit 100 or more files at a time and use a 'Find And Replace' tool to make changes to all of them at once. After hitting 'Save All' I am forced to go back to filezilla and click yes to hundreds of damn prompts.. RIDICULES.. things like this cost us developers money in the long run.

I have used several other tools who have the functionality to remove prompts and NEVER* once ran into any issues.

I left smartftp because it is pure crippleware.
I came back to Filezilla hoping I had previously just missed some method to remove the prompts.. After coming across this page I am completely blown away by the complete stubborn and ignorant ideology of the developers of filezilla.

Why would you not at least implement this as an option? What possible reasonable excuse could you have? Its crazy you are not doing this because you believe it is not safe.. How would you feel if the U.S. (or what ever country you are from) made unprotected sex illegal because obama believed it as not 'safe'. You would no longer be allowed to have sex without protection even if you knew the risks and accepted the responsibility. (I know that does not entirely relate to this, but you get the point)

The Point: You developers need to grow up a bit. Implement this so we can all go back to loving this great open source software.

[Martin Šustek]

I'm also considering prompt as annoying.

I fully understand reasons why immediate transfer can damage file, but I'm using FireFTP (FTP plugin for Firefox browser) with this capability for several years, and it never happened in my case. I think that FireFTP is also capable to delete temporary file after editor is closed (by watching process status, again with no prompt).

Waiting reasonable time (few seconds, it can be configurable) after last change of file before transfer is a good idea (or look at FireFTP's sources, how it's done).

If user is enough responsible for clicking button at right time (and guess the right time), then he is also enough responsible to select, if he want use prompted or automatic delayed upload.

No one want you to use this feature, if you are afraid of security of your data. But you can implement it for users who want it and consider it safe. Sometimes software development isn't about you, but about users of your software.

[Peter Hollo]

Wow, I didn't expect this! I just discovered FileZilla was available for Mac, having switched from PC. I used WinSCP on PC, and FileZilla seemed like the best alternative - but I immediately got annoyed at the prompt on saving remote files, which WinSCP never does.

I'm quite gobsmacked at the blank refusals throughout this thread. Off looking for alternative software now I guess.

[Tim Kosse]

I really need to install an addon for trac to permanently close a topic...

[Redsandro]

Or fix the bug and satisfy Pw-1 people, where Pw = world population. ;)

[Ruffin]

Isn't there another option, like making this a command-line preference? I use Transmit on OS X and WinSCP on Windows, both of which have auto-upload on change for edits initiated within the client of files already on the server. Perhaps I'm missing something, but the same issue described here seems to happen for "server-side" editing too.

Two small points.

1.) If I choose to edit on the server with FileZilla as the go between, I really don't expect to see a prompt with each edit. I'd expect the file to change as I change it. Edit, save, alt-tab FileZilla, click OK, alt-tab browser, reload, alt-tab gvim is a pain.

2.) At least provide the option with a warning. So automatically updating on a change might open the possibility of whacking a file -- let the user decide if that's a chance they'll take. I don't have any trouble with WinSCP and Transmit, and one of those is a pay to play. I don't think it's killing them with support time.

Even a command-line option would do the trick, hiding from the masses but allowing those that need the feature to be more productive to give it a shot.

Alternately, what's a client on Linux that has this feature? ;^D

I'm going to reopen, but only because I would have submitted the same feature request if this hadn't been here. Let's say I change it by asking for a cmd-line option instead of a radio button/check box in settings.

[Ian Dunn]

I think codesquid has a valid point about the local and remote files being overwritten. I experience that with other S/FTP clients about once a month. It's generally not a problem for me, though, since I still have the file open in the text editor and just re-save/re-upload it. I also have backups of all my sites.

I think it's smart to have the default behavior set to prompt the user before uploading, but I also strongly feel that there should be an option to let the user bypass the prompt and have the file automatically uploaded. Yes, data corruption is a problem, but having to manually confirm a prompt 100 times a day (literally) is also a problem.

In my opinion, manually confirming the prompt is a much bigger problem than occasional data corruption. I would gladly accept occasional data corruption if it meant I wouldn't have to confirm the upload every time.

Here's what I'd propose as a compromise:

• Keep the current behavior (prompting for each upload) as the default
• Add a new option to bypass the prompt (disabled by default)
• If a user enabled the new option, show them a warning that lets them know they will occasionally experience data corruption if they use this. Make them confirm that they accept that risk.
• If they confirm that they accept the risk, then don't show the prompt and automatically upload files.

I think that would satisfy the concerns of both sides of the issue.

[Ray McDonald]

I can't believe, that this annoying dialog box still appears and that the patch has not been implemented.

It's totally frustrating !'''

[Alexander Schuch]

This is a duplicate of #2914.

[Gabriel Tenita]

So, even if I never open the file in another app, I'll still have to confirm everytime that I'm really not opening the file in another app so, please let me save my work?
I guess Filezilla knows better than its user...

[Gabriel Tenita]

And this certainly is not a duplicate of #2914. This asks for the confirmation to be optional, not for a separate setting for auto upload and overwrite. You may as well mark all tickets asking for settings modifications as duplicates.

[Holly]

Since it's absolutely 100% impossible to detect a safe time for the transfer, FileZilla needs to delegate this responsibility to the user.

Yes, please do exactly that.
Please let the user decide whether it's safe or not by letting them enable auto-upload if they so choose. Note that "safe" would also be satisfied if potential file corruption is fine to the user. After all, it's pretty easy to prepare for, and depending on the kind of the project, it may very well not be an issue in the first place.

Many other clients allow it already, some even by default, and there are no issues there. I have used auto-upload in WinSCP for literally decades and have not once experienced file corruption.

My current use case is regularly editing a cronjob file where file corruption is both extremely unlikely and inconsequential if it were to happen.