Queue autorecovery after crash

[ifezs001]

Filezilla forget the download/failed/succesfull Queue after closed the client

It should be viewable after close / restart.

[ifezs001]

I run only one Filezilla at one time. I tried it on Linux and Windows as well.

The problem is the same.

I think the Queue should be saved. Like it happens in FlashFXP.

[Tim Kosse]

Duplicate of ​https://sourceforge.net/tracker/?func=detail&atid=372241&aid=1912671&group_id=21558

[ifezs001]

I think if teh same user close the Filezilla and then open it again, it should remember the download and failed queue.

I think it is still a bug.

Why should I re-add all the items if my OS freez? Why should I check with a differnt software that what was the only 1 file which did not downloaded well?

[Tim Kosse]

Performance reasons. Writing the queue to file all the time would cause an extreme slowdown. Besides, a good operating system never crashes.

[ifezs001]

I think you have right. A good operating system never crash. But we don't have OSs like this.
Although a good software can write a file without any extreme slowdown.

So I think it is a problem. If soemthing happen it should remember for the actual queue.

As I said: Check FlashFXP. It can do this "feature" or check the KDE based ftp client as well.

It is still an existing BUG.

[Tim Kosse]

Like I said before this behavior is by design, always writing to the queue file would eat too much performance.

[ifezs001]

If it is by design, I think we have some problem with the design.
Why can other ftp softwares handle it?

I know that this is a free project, and I like it very much, but this is a bug not a feature.

You should create an option where you can turn ON/OFF the queue save option. And you can say that it could cause some slowdown.

Is it a good way? What do you think?

[RapteOfSuzaku]

I thought the request title was funny, so I read. But I, too, have often wanted this feature.

In the admittedly brief amount of time I've thought about it, I can't seem to figure out why one would have to write to the queue file so often as to degrade performance. Personally, I wouldn't even bother keeping track of the download progress. What I would want is just something that lets me pick up where I left off without having to figure out what I was in the middle of downloading. Really, the download progress is already stored implicitly in the current size of the downloaded file... the resume feature already makes use of this, so why not reuse that for this?

When a new item is added to a queue, write that information to a file. When an item is removed from a queue (user action or completion/failure of transfer), remove the corresponding info from the file. No need for updates in between.

After that basic functionality, things like "auto-resume queued files from previous session(s)" could be added in (separate from the already in place "file exists action" setting). But for now, I'd be fine with the program acting as if all the restored queue items are at 0% until I process the queue and choose to resume.

As for why this is useful, it isn't only for random crashes. FileZilla Client is now far more stable than it used to be (can't remember the last time it has crashed on me), and my OS hardly ever gives me any troubles. But what if I want to reboot (installed something big, want to physically clean the computer fans, need to rearrange some cords...)? What about power outages or stupid neighbors that for some reason mess with the fuse box and flip the wrong switches (ah, college dorm experience)?

Or am I missing something that would unavoidable degrade performance? Anyways, thanks for reading (and for the ever improving program)!

[RapteOfSuzaku]

(whoops, just CCing myself now that I see how)

[Tim Kosse]

But what if I want to reboot (installed something big, want to physically clean the computer fans, need to rearrange some cords...)?

FileZilla saves its queue and cleanly closes itself you log out of the Gnome or Windows desktops.

What about power outages or stupid neighbors that for some reason mess with the fuse box and flip the wrong switches (ah, college dorm experience)?

Been there, done that. If my power goes out, my uninterruptible power supply kicks in and my system cleanly shuts down.

If you don't have have a UPS and your power goes out, you'll have worse problems than a lost queue. Filesystem corruption and the loss of all data in the write cache. Potentially even hardware.

Or am I missing something that would unavoidable degrade performance?

Saving large queues can take quite some time and consumes quite some CPU power to build the XML.

[ifezs]

Hi!

I agree with RapteOfSuzaku. I created this report long time ago. I added a normal title, but the developper got angree, because I told to him that this is a necessary function.

Interesting that in the FlashFXP they could implement this feature, and not slower than the Filezilla.

I think now that they can not do this development, because this feature could be optional choosable option in the Filezilla options.

I can not understand why they don not want to do that except if I am right and they don't know how to do that.

I wonder why they did not deleted this bug report long time ago, when they moved to this new bug tracking tool.

Maybe they will now. :)

[Tim Kosse]

Can FlashFXP handle queues with a million files? FileZilla can.

[RapteOfSuzaku]

Yeah, the developer is acting rather strangely. I'm perfectly fine if he labels this as a very low priority issue. Really, I consider it a rather low priority thing myself. I can agree with everything the developer has said except the notion that this feature can't be implemented without detrimental effects.

The attitude taken towards the bug report and the arguments made against the validity of the bug are just ridiculous. If it takes a million files to cause the degraded system performance, then this is clearly a feature perfect for having a toggle button in the settings. I've never had more than 30 files listed and usually I have about 5 total.

And don't try to tell me that the time it would take to manage the XML couldn't be hidden from the user. Computers are faster than users. Heck, put "restoring queues from crashed session" in the status bar and update the queues every five seconds or so with whatever has been read into memory in that time.

Rather than saying it can't be done, just say that you don't think it is worth doing. How about you return the title to the original one and then put the priority down to low?

[RapteOfSuzaku]

oh, I can change things? So I will, then.

[Tim Kosse]

I never said it can't be done, I said that I won't implement it due to performance reasons and because it shouldn't crash in the first place.

[ifezs]

"I never said it can't be done, I said that I won't implement it due to performance reasons and because it shouldn't crash in the first place"

Oh... come on. FlashFXP can handle hundreds of files. That is enough. Although it can handle the queue backup and restore function.

I don't think that this is the best solution. I mean you won't implement it. During this conversation maybe you could start to make this change instead of arguing.

As I said there could be an option button within preferences and next to this option you could write that it may cause performance problem. Than your problem solved and the users can decide.

Every program can crash. Doesn't matter why. But it could happen and it happens all the time. It could be safer if you implement this feature.

That is all. Although it seems to me that this function can't be done by you. Still keep my view as you were able to read.

Thanks.