Delete files - Wait until other operations are finished

We welcome any suggestions for new features or improvements in Altap Salamander. Please post one suggestion per report.
Slanec
Posts: 66
Joined: 17 Nov 2009, 19:00

Delete files - Wait until other operations are finished

Post by Slanec » 14 Nov 2010, 02:23

It's simple as that. Could Delete file/directory dialog also have an option to run after all other Copy/Move (and in the future also actions related to archives, I hope) operations? When there's a complicated chain of Copy/Move actions going on and I want to clean up after it, I have to wait for it to finish and only then delete all the files ... which is not a trivial task most of the times.

User avatar
Ether
Posts: 1459
Joined: 10 May 2007, 16:08
Location: Czech Republic
Contact:

Re: Delete files - Wait until other operations are finished

Post by Ether » 14 Nov 2010, 13:50

+1 for the same reason.
Ελληνικά rulez.

User avatar
SelfMan
Posts: 955
Joined: 05 Apr 2006, 20:51
Contact:

Re: Delete files - Wait until other operations are finished

Post by SelfMan » 14 Nov 2010, 16:05

+1 from me (even if I remember right I already requested this feature)

Slanec
Posts: 66
Joined: 17 Nov 2009, 19:00

Re: Delete files - Wait until other operations are finished

Post by Slanec » 14 Nov 2010, 16:33

SelfMan wrote:(even if I remember right I already requested this feature)
True story, http://forum.altap.cz/viewtopic.php?f=3&t=2952, sorry I didn't look it up first.

It is said there that:
Jan Rysavy wrote:We have two problems here:
1. The Delete operation doesn't need to have confirmation dialog box or this dialog box could come from Windows (Recycle Bin). So we have no place where place the queue option.
2. The proposal is potentially dangerous. Imagine situation when first Copy/Move operation will fail (out of space, overwrite confirmation, other error, or just cancel). The queued Delete operation will delete your only data :(
1) Oh. I don't know anything about this, but the Win dialog box could be replaced, could it not? Is it hard to detect Recycle Bin usage? Is there a hidden technical problem behind this making it a lot more complicated than it seems to be on the first glance?
2) Okaaay. Seriously, the action queue is already NOT being paused/canceled when one of the Move/Copy actions failed? Well it should be, it's a chain of actions (likely to be connected) and every single fail could be a problem... +1 for throwing an interruption in when there's a fail.


EDIT: And if somebody's going to point out that the Move/Copy/Delete actions might not be connected to each other and therefore the Cancel on the entire queue could be a problem, well, detect it then. It should not be a hard thing (nor a very easy one too) to detect whether a new Copy/Move action would affect one of already existing action chains (shares a destination or target path with some of the actions in there) multiple Copy/Move chains. Every new action in the queue would be assigned to some of the already existing chains (or to two or more of them - then they would have to be merged carefully). And if there's a fail somewhere, there still would be actions possible to perform, since it is certain that they can't be affected by the fail.
example:
Let's have drives C:, D:, E:, F: and G:.
Copy a file from C: to D: -> creates a queue with one request (1 chain)
Copy a file from F: to G: -> inserts a request into the queue and because the new action does not affect any directory from the first Copy action, it creates a different chain ... it would be NOT performed immediately but in the case of the first action failing, it could be safely done. And vice versa - if this actions fails, the following one could still be performed:
Copy a file from D: to E: -> request into a queue, connects to the first chain since the first action involves D: drive.

Um, did I say it understandably or should I make an example image?

User avatar
Georgd
Posts: 98
Joined: 24 Jul 2006, 17:13

Re: Delete files - Wait until other operations are finished

Post by Georgd » 28 Jan 2011, 01:07

Slanec wrote:It should not be a hard thing (nor a very easy one too) to detect whether a new Copy/Move action would affect one of already existing action chains (shares a destination or target path with some of the actions in there) multiple Copy/Move chains.
Personally, I extensively work with symbolic links, most Win7 users work with the default symbolic links without noticing it. Main point here: 2 paths may have the same "physical content", but the content is not aware it is contained in 2 paths. I'm not sure this can never pose the situation that it seems there's no connection between two operations - but in reality there is one. Same applies for Win 7 libraries etc.
Hence I do see a potential risk and do not want to use a queued delete but to control the results of previous actions before deleting. If queued delete will be added to Salamander I'm fine as long as it's not the default behaviour ;-)
Using Salamander since v 1.52

fraktik
Posts: 206
Joined: 27 Apr 2007, 12:13
Location: cz
Contact:

Re: Delete files - Wait until other operations are finished

Post by fraktik » 05 Feb 2011, 07:50

+1
I am using symbolic links too, but queue is good option - becouse many times (work with NAS etc) many paralel operation multiple time consumption....
I think its potencialy dangerous, but this decision is on users - if they want to risk and use faster way, or if they want to check file structure before final deleting!

Slanec
Posts: 66
Joined: 17 Nov 2009, 19:00

Re: Delete files - Wait until other operations are finished

Post by Slanec » 24 Feb 2011, 10:10

So, basically, we all kind of agreed on this:

1) Delete queueing is possibly a good and desirable feature, it simplifies complicated chains of Copy/Move actions.
In my case, after the desired chain, I usually have to delete like a dozen of files from distinct sources. My current solution is to enqueue Move action to some "toDelete" folder for each of those files. Which is terrible, because it's slow.
When Salamander will be able of on-background actions with archives, the Delete action will too be very handy.

2) When one of the actions in queue fails, it is potentially dangerous to perform any action - even if it's reversable. Let's think of some solutions!
- What about this: The dialog "Action failed!" could contain "Continue All" (all other actions in queue would be performed anyway and the failed file would get focused in Salamander), "Decide All" (all other actions would pop out once more to be confirmed or cancelled), "Cancel All" buttons. This seems like the right way to go for me...
- The original thread http://forum.altap.cz/viewtopic.php?f=3&t=2952 also suggests doing the queue actions anyway and rely on confirmations like Confirm on: Non-empty directory delete which are indeed checked by default.
- Since we care about user's data, the feature could be available only for files on local disks with Recycle Bin on. That's like my Move to toDelete folder, only faster and as much as safe. It's not a full-spectral solution, but helps anyway.
Any other ideas?

3)
Jan Rysavy wrote:The Delete operation doesn't need to have confirmation dialog box or this dialog box could come from Windows (Recycle Bin). So we have no place where place the queue option.
Still no idea here. Is it technically possible to make that dialog by ourselves and bypass the Windows one?

fraktik
Posts: 206
Joined: 27 Apr 2007, 12:13
Location: cz
Contact:

Re: Delete files - Wait until other operations are finished

Post by fraktik » 24 Feb 2011, 14:25

Slanec wrote:Since we care about user's data, the feature could be available only for files on local disks with Recycle Bin on. That's like my Move to toDelete folder, only faster and as much as safe. It's not a full-spectral solution, but helps anyway.
Recycle Bin is applicated only - if this option is "on" and the deleted files arent bigger than dedicated place for him.

Post Reply