Opened 16 years ago

Closed 9 years ago

Last modified 9 years ago

#2914 closed Feature request (wontfix)

Option to auto upload & overwrite on external edit

Reported by: pontiac76 Owned by:
Priority: critical Component: FileZilla Client
Keywords: automatic-upload-on-external-edit Cc: pontiac76, Tim Kosse, Alexander Schuch, bl4nkeh@…, Freer, guidod@…, noel_fb@…
Component version: Operating system type:
Operating system version:

Description (last modified by Alexander Schuch)

I've found it rather useful to use the VIEW/EDIT to download a file I need to edit, make my change then save it in the external editor, then have the client realize a change (Based on time/date/size/whatever) and then request to upload. What I'd like to see added (And its a very simple thing to do) is have it have that dialog to give me the option to allow automatic upload and overwrites the file on a discovery of a change to the file, without my having saying YES or NO every time.

Change History (51)

comment:1 by Tim Kosse, 16 years ago

Unfortunately fully automated upload-on-change can result in data loss, as it is technically impossible to detect when a program has finished writing to file. It is the user's task to tell the client "go ahead, the file has been fully written, it is safe to upload now"

comment:2 by pontiac76, 16 years ago

Shouldn't that be up to the user to decide?

in reply to:  1 comment:3 by Troop116rules, 14 years ago

Status: closedreopened

Replying to codesquid:

Unfortunately fully automated upload-on-change can result in data loss, as it is technically impossible to detect when a program has finished writing to file. It is the user's task to tell the client "go ahead, the file has been fully written, it is safe to upload now"

I think it is possible, because SmartFTP does automatically upload after editing. I don't personally mind having to go to FZ every time I edit something, but my friend was irritated, because he was used to SmartFTP. I thought about it, and I think it would be nice if there was just an option in settings to allow automatic upload. The option is critical, because prompting the user is good when user error occurs. He may edit something he didn't want to, and because he saved it and it automatically uploaded, it's gone now. But, some people like this feature, as it is less of a hassle.

comment:4 by Tim Kosse, 14 years ago

Resolution: rejected
Status: reopenedclosed

SmartFTP gambles with your data.

comment:5 by loukote, 14 years ago

Resolution: rejected
Status: closedreopened

Shouldn't that be up to the user to decide?
IMHO it should.
+1

comment:6 by Sasha Shepherd, 13 years ago

I would like to second this feature request.

Konqueror, when used as an FTP client, is able to do it.

I run an older computer, with only 1GB of RAM. And I often have many programs open. So, every time I switch over to Filezilla, it has to page out and it takes a couple seconds to redraw the window. When I do this dozens and dozens of times, for instance tweaking CSS, it gets so frustrating.

This is so annoying when I am, for instance, just adding a missing ; to a php line or something.

By default, the current behavior is correct. But there SHOULD be a setting to automatically upload. I am sure after 1 second the 2kb file will be totally uploaded.

As an alternative, it would be nice to have a global hotkey that confirms the file is uploaded. Instead of having to switch to the window, hitting say shift+ctrl+s from any program to confirm.

comment:7 by Matt, 13 years ago

Cc: bl4nkeh@… added

@codesquid: I used SmartFTP for quite a while with this feature and never had any problems.

SmartFTP does basically what FileZilla does (checks for a change in the last modified date), but instead of prompting the user if they want to upload the change, it does it automatically. While the file is being edited it sites in the download queue, so once you're done editing, you can just remove it from the queue and not worry about it uploading any longer.

I'd love to see this feature in FileZilla, as it's a pain when you're doing minute changes and keep having to tab back and forth between windows to upload small changes.

comment:8 by pontiac76@gmail.com, 13 years ago

It has been three years since I've made this request. I am the same guy, just can't remember the email address I reg'd with! :(

With certainty, the thing about "gambling with your data" seems to have gone out the window.

First, several applications out there successfully note when a file change has been done by monitoring for changes itself, either on the directory or on the file itself. Dropbox for instance will monitor any and all changes within itself and change files. It is even smart enough to abort the current transfer if the file has changed when the file is still being uploaded to the server. I'm not asking for the "stop and retry" transmitting in this ticket, just the option to get rid of the dialog and have it start the transfer on its own.

Second, writing data locally on your hard drive is going to happen a lot faster than uploading the file to any server, and I'd wager even if you're running on a giggabit network.

Third, in the Windows environment its easy to see if one has read access to the file. When the software notes a file size change, or a windows event that a file has changed, a simple open and read the first few bytes is all you need to confirm if the upload is going to work. I've not developed in Linux (I use it daily though) and Dropbox does its thing in the Linux thing as well!

Fourth, with the advent of web technologies blooming from what it was three years ago, until today, I personally think it is a much more useful function than being bugged by a dialog.

Fifth, the data lives on your local machine. Whether or not it entirely gets to the other end obviously is important, but highly doubt it'd get into a "gambling with your data" anyways since all you have to do is retransmit if bad data is suspect.

The dialog that shows up saying "This file has changed" so FZ seems to know that the file has changed. Please add a toggle that lasts just the session and/or for just that one file that will click that "OK" button so the upload kicks in. With a timer to poll file changes (User configurable?) it'd work.

comment:9 by mahakala, 12 years ago

Operating system type: Windows
Priority: normalhigh

bump need it, too ;)

comment:10 by Alexander Schuch, 11 years ago

Keywords: automatic upload external edit added

comment:11 by Alexander Schuch, 11 years ago

Suggested by Grzegorz:

"I think this shouldn't be added into options/file-editing tab.
It'd be better to have a tick in a prompt "File has been edited" that says "Upload all changes to this file in this session automatically".
This way it will be safe for everyone, you'll save file once, do typical FileZilla procedure (open the window and click confirm upload) but just in the middle there will be one little tick to disable the prompt for every other edit of this file in this session and upload immediately on save."

comment:12 by Alexander Schuch, 11 years ago

A patch (maybe outdated) is available at #4694.

comment:13 by Alexander Schuch, 11 years ago

Another patch is available in #5705.

comment:14 by peter_spencer, 11 years ago

Operating system type: Windows
Priority: highcritical

This annoying dialog box still appears and that the patch has not been implemented.

First, I do like the idea of the session option.

But an global option must be added into options/file-editing tab to == hide the FUCKING per-session prompt ==

Users that don't know what they are doing should NOT USE FTP !! THIS IS NOT FOR IDIOTS

This prompt appears since the days of beginning and it's totally frustrating '''

comment:15 by peter_spencer, 11 years ago

btw, this BITCH ASS issue has been opened by me 5 years ago

comment:16 by Alexander Schuch, 11 years ago

Priority: criticalhigh

comment:17 by Alexander Schuch, 11 years ago

Another interesting idea about how to configure this is given in #5157.

comment:18 by xblondel, 10 years ago

Operating system type: Windows
Summary: Option to auto upload & overwrite on external editAutomatic Upload Needed

I also need this option to be implemented
I was using winSCP, which don't prompt , do auto-upload on change and never had any data corrupted.
It is really tedious to come and click "yes" each time
I come specially and create my account here for this feature (also asked on #4694)

refusing this option because accidents can happend don't seem a good reason... Life is full of accidents.... we have to live with them (do our back-ups ... )
and the lack og this option can't prevent all the accidents anyway...

comment:19 by Alexander Schuch, 10 years ago

Operating system type: Windows

comment:20 by Alexander Schuch, 10 years ago

Summary: Automatic Upload NeededOption to auto upload & overwrite on external edit

comment:22 by Roony Alvarez, 10 years ago

posted a ticked, got marked as duplicate. fancy that.. 6 years.. maybe you guys should change status to "it-will-never-f*ckin-gonna-happen-period" so we get the hint..

pd. you do not have to do a thing, alright. some of us will just stick to crossFTP and pay for a license. be cool.

comment:23 by Freer, 10 years ago

Cc: Freer added

There is no good reason to not put this as an option. Explain possible risks if necessary, but this is particularly annoying to developers making many small changes to a remote server. For those of use who have supported the FileZilla project time and time again to keep this technology improving and open to everyone, it's annoying that such a simple and useful feature has been ignored for six years. It's almost worth giving up the best user interface in FTP for this one option.

I for one will pledge another donation if this is implemented, if that will motivate its accomplishment. It would be well worth it for what it would save me in time.

comment:24 by Guido D, 10 years ago

Cc: guidod@… added

+1
Transmit has this and works perfectly. Seems to upload to a temporary path and then (probably after some kind of integrity change) replace the previous version of the file.

comment:25 by Alexander Schuch, 10 years ago

Another summary is available at #7791.

comment:26 by BloodyRain2k, 9 years ago

Priority: highcritical

Bump because I have a problem with a webhost when I'm using NP++'s plugin so I started using FZ for that.

Works ok but it's a little annoying to have to manually confirm the upload all the time and I'm sure that there are ways to detect whenever a file gets written to or not, either it has a write lock or it doesn't.

Or monitor the filesize for 2 seconds, if it doesn't change in that time it's unlikely it will in the next.

As for the reason of gambling your data, you might as well lose the data by manually clicking overwrite when you didn't mean to, we all had such moments one time or another.

It's also a joke marking #8194 and #8784 as duplicates when this ticket is being ignored for by now already 7 damn years.

Either try to implement it as an additional option or write in big red letters on the front page "AUTO UPLOAD WILL NEVER HAPPEN" but stop leaving this issue open in the hopes people will stop caring, at the point they do, they probably started using another client already anyways.

comment:27 by Daedalon, 9 years ago

+1

A bit of searching revealed that this is a duplicate of #1952, #1979, #2765, #2992, #4694, #4932, #5005, #5157, #5295, #5303, #5582, %5705, #7796, #7989, #8194, #8611, #8784, #9674, a total of 19 tickets. The most active one is this, #2914.

This may be the most wanted feature for FileZilla.

Version 0, edited 9 years ago by Daedalon (next)

comment:28 by Roony Alvarez, 9 years ago

lol. another year.
this is the classic "[faux]oss way": "if you dont like it the way it is, go fuck yourself. (or fork it)" X)))

comment:29 by Daedalon, 9 years ago

Apologies, #4932 is not a duplicate of this. That makes the total count be 18.

comment:30 by Daedalon, 9 years ago

Sorry for another micro-update as there's no editing the comments here. A tiny correction: the above list omitted #7791, so the count is 19.

Also made a typo so #5705 wasn't linkified. It includes a patch for this from 4 years ago. Also #4694 includes a patch, that one from 5 years ago.

There's already an option to overwrite files that already exist, and there's a warning / instruction on avoiding data loss. I believe FileZilla will be better for having a similar option for auto-uploading edited files.

comment:31 by peter_spencer, 9 years ago

Year 7 and no changes!

Thousands of people have requested this feature...

Unbelievable'''

comment:32 by Roony Alvarez, 9 years ago

@Daedalon dont beat yourself up, mate. this simply will never happen. as you may have read in other threads, they claim its "technically impossible" which is completely stupid and another way to say "we dont fucking care. beat it"... 7 years later... yeah, i got the hint.

go get yourself a copy of crossFTP and rejoice. it is java freemium but works perfectly.

comment:33 by Daedalon, 9 years ago

@legion1978: Thanks, had a look at that. Unfortunately the free version does not have SFTP support. Regarding this ticket, it has been a slight issue for me many times, but luckily nothing major.

Most editors have built-in FTP/SFTP support and automatically upload saved remote files. Notepad++ and Sublime Text are among the most fully-featured free ones. When the main purpose is to edit files, the most effective workflow for me has been to use an editor with FTP support instead of combining programs.

Regardless, FileZilla would be better with an option to auto-upload on save.

If one was forced to guess why this hasn't been implemented despite other programs doing so, one could suspect that people get rooted in their opinions. It can be taxing to admit that one's own argument from the past does not hold water in the present. One may also speculate that using more critical language would make it more unpleasant for a dev to start working on the issue, making it less likely to happen. Constructive approaches like #7791 seem more likely to reach the desired result.

comment:34 by peter_spencer, 9 years ago

I also want to recommend Komodo Edit - it is Open Source, based on Mozilla's XUL Runner and available for all platforms

It supports FTP and SFTP, and respects your ~/.ssh/config file.

http://komodoide.com/komodo-edit/
https://github.com/Komodo/KomodoEdit

comment:35 by peter_spencer, 9 years ago

I've uninstalled FileZilla - fuck this project.

comment:36 by Roony Alvarez, 9 years ago

@Daedalon well then buy it :) hehe i did buy it just out of gratitude. i dont even use all of its features, but i have always had good support and the program is solid. worth it.

@peter_spencer lol >> and thnx for the suggestion ill give it a look, though its been years since i bounced between bluefish and geany, and finally settled for geany.. but its always nice to have more options with extended features if needed :)

comment:37 by Noel, 9 years ago

Men,
Just add a checkbox.
Just add a f*ing checkbox.
Just add a f
*ing checkbox in the Option Menu.
Just add a f*ing checkbox in the F*ING Option Menu.
Just add a f*ing checkbox in the F*ING option menu in file edition!!!
Just add a f*ing checkbox in the F*ING option menu in F*ING file edition!!!

Just FK THE F*ING OPTION!!!!

LET ME BEEEEEE!!! LET ME BE HAPPY!!!
Internet was created to read files between universitys AND NOW WE ARE USING INTERNET THE SEEEE A LOOOTT OFF PORRRRRNNNNN!!!!!
YOU CREATE A FILE UPLOADER AND WHY COULDN'T BE A FILE EDITOR HELPER!?!?!?!?!?!?!

:)
Thanks.

Can I pay for that? How many money? Who should I pay it?

comment:38 by Noel, 9 years ago

Cc: noel_fb@… added

comment:39 by SM, 9 years ago

This one seems surprisingly easy. That 'codesquid' says it's impossible or dangerous is surprising.

You're obviously hooked into the file somehow, and firing the dialog due to some event. Apparently that event is not an 'on-change' event that happens at the end of the file being successfully changed, or there would be no fear of 'data corruption'. And an event firing at the start of a file being changed would be useless. So you're either hooking the dialog to a timer, or to the FileZilla window focus returning, and discovering the changes then. In either event, it's simple.

  1. You discover a file signature/size has changed. Set up a timer, say, for half a second (which is like forever in computer cycles amirite?).
  2. The timer event fires.
  3. Check the file signature/size again, comparing it to the first change.
  4. Is the file still changing? If so, set up another timer for another half a second.
  5. If not, destroy the timer and upload the file.
  6. If you want to be EXTRA careful with the users' files, then don't destroy the timer, wait a few more half-seconds just to be sure the file absolutely isn't changing, and THEN destroy the timer and upload that version of the file.
  7. If you want to be neurotic, check the file signature/size after the file has been uploaded. If it's changed for some reason since the last ten times you checked it, set more timers to check the file state.

Worst case scenario, if you upload a half-saved version and quickly update it a half-second later with the fully saved version, the user probably won't even notice. And if they DO notice, then they'll PROBABLY understand that they're using an FTP program that they've SET to automatically upload their files, and they're doing something strange with the file anyway, and they probably EXPECT the file to be half-saved with the way they're screwing with the filesystem.

That's just my two cents on a feasible implementation for this seven year old feature request. Be glad I just bumped it and didn't create a duplicate ticket. ;)

comment:40 by SM, 9 years ago

Oh, hey, otavio021's patch looks real nice. I bet 'codesquid' uses that version at home. Way to dogfood! ;)

comment:41 by Roony Alvarez, 9 years ago

it still amazes me how people get in here and make them arguments and explanations and reasons.. and all that get in return is silence :) i wonder what would it take to someone actually from filezilla responds (without being an a-hole)--
anyway i see crossftp enqueues them files after i edit/save.. even with with only miliseconds apart from each other. they just get in line and up they go. never had an issue. i suppose filezilla dudes have more important things to worry about

comment:42 by Roony Alvarez, 9 years ago

..and yet i found this https://forum.filezilla-project.org/viewtopic.php?f=3&t=34730&p=129157
so they have the audacity of calling "gambling" to file change detection. wow. just thrilling. (or pathetic,since it obviously can be done, and it IS being done by others)
X)))

comment:43 by SM, 9 years ago

I have never, ever, in all my years of using SmartFTP and others like it, EVER had my data corrupted. Ever.

But I HAVE been annoyed, repeatedly, by useless modal windows that I always click the same damn button on, which conspicuously DON'T have a 'never show this again' checkbox. It's a waste of time, a waste of clicks, and a waste of money buying a new mouse after all that unnecessary clicking wears out the old one.

comment:44 by Roony Alvarez, 9 years ago

its clearly a shortcoming on their side. either they dunno how to do it (hardly) or they just dont fucking want to :))

comment:45 by SM, 9 years ago

Oh, could you imagine doing a find-replace in all open files? Filezilla would just pop up a couple hundred modal dialogs wouldn't it? Yes, it appears that is exactly what it does, as I've just tried it. They pop up sequentially, one after the other.

Actually, maybe there's another way around this. Automation programs like AutoIt, among others, can be made to identify popup windows and automatically click on buttons. And it looks like some frustrated users on the forums have done just that.

https://forum.filezilla-project.org/viewtopic.php?t=20386&start=15

It's just SAD that incompetency and laziness on the part of the programmers of this software have caused so many USERS to program so many of their OWN solutions. It's too bad Filezilla isn't opensource. ;)

comment:46 by Roony Alvarez, 9 years ago

lol yeah been there myself.
apparently their "fear" of file corruption is more like acknowledgement of their incapacity [and/or shame of not] getting it done. productivity anyone? heh!

i never knew more stubborn people before... well maybe that hard ass rhythmbox creator and his its-fine-for-me-so-use-it-just-as-is-or-go-fuck-yourself attitude X))

this is water under the brigde for me --i come back now and then to see if they came to their senses.. or just for the giggles X))

comment:47 by Krzysiek Dróżdż, 9 years ago

Is there ANY feature that IS possible to implement?

  1. Automatic uploads? - "it can't be done" (it apparently doesn't matter, that almost any other FTP client has this feature).
  1. Storing encrypted password - "it makes no sense, because there is no way to encrypt passwords so they are secure" (apparently KeePass is soooo useless and unreal...)

It looks like FileZilla was implemented by some alien from another galactic and now it's impossible to do anything with it's code...

comment:48 by Monsto, 9 years ago

Resolution: wontfix
Status: reopenedclosed

For every user that posts here, there's 1000 that install, then go "wtf? No option? Uninstall." This is what I did and created an account specifically to make the point.

Dear maintainers:
The bottom line is that people WANT to use the program and the lack of such an option is a complete dealbreaker. Yes I had it installed, found that I couldn't auto-sync files at my option (like so many other apps), and decided to use something other than this.

It's the FOSS cancer: developer arrogance.

comment:49 by niaccurshi, 9 years ago

I'm also registering to say that the lack of option for this is what is forcing me to move from Filezilla as an FTP solution. It should be up to me as the user whether I want to worry about data corruption (which in general isn't an issue, because if it's ever happened with another FTP, not that I've ever seen it, I've undone it by simply resaving the local file).

It's a shame such a great product harms my productivity compared to other products and so, unfortunately, needs to be left behind.

comment:50 by Alexander Schuch, 9 years ago

Description: modified (diff)

An alternative approach is proposed in ticket:7791.

in reply to:  50 comment:51 by Roony Alvarez, 9 years ago

Replying to ci-dev:

An alternative approach is proposed in ticket:7791.

df ¬¬ where exactly? just more of the same crap. moving on X))

comment:52 by Alexander Schuch, 9 years ago

Keywords: automatic-upload-on-external-edit added; automatic upload external edit removed
Note: See TracTickets for help on using tickets.