Copy/Move Queueing

I love the copy/move dialog in dopus with its pause/resume and transfer speed indicators. A mate and I were discussing it, and we both think that the only thing it's lacking is the ability to queue up multiple operations.

For example, I often do stuff like this:
-Start copying a large number of files from one hard drive to another
-Realise there were actually more files that I wanted to copy
-Start another copy dialog up to copy those files
-Manually pause the second dialog so the hard drive doesn't get flogged and fragmented, and resume it again when the first has finished.

What would be cool is if there was an option to queue up the second transfer onto the end of the first (or some other position), automatically, or to allow the user to kind of merge to two dialogs together by dragging and dropping or something.

An extension to this would be to have another option that detected if two transfers were using a common hard drive and automatically queue the second transfer.

i.e. Two transfers:
C: -> D: and
D: -> E:

D: is in common, so put both transfers in the same queue. Maybe have some kind of file size threshold below which this queueing thing didn't happen as well.

What do you think?
-Sam.

I think it's a good idea. There are several threads about it already, though. :slight_smile:

I haven't read the other postings but, that almost sounds like a job scheduler... having to append one job to another, dependencies, start-fail relationships. yikes.

yikes.

Nothing scary about it: Create a new queue, add copy and move commands to the queue and then start the queue. This could be done for any commands actually.

+1

One of the other threads:

[Automatic Copy Queue)

Whoops, probably should have searched a bit harder before posting.
I guess multiple posts mean that there are lots of people wanting this feature though :slight_smile:

In what situation would there be dependencies?
In my example, if the first copy failed (due to a file in use, or an overwrite confirmation or something), the second one would just start copying regardless.

Provided there weren't any files in common.

The only thing that might get you into trouble is if operation 2 uses the files output from operation 1. Then op 2 would depend on op 1 I suppose. That would be trivial to check for though, so easy to avoid.

Edit: Here it is. Something similar to this program would be great.
pineda.no/products/securecopy/
I tried this a while ago, but occasionally it would corrupt my files so I stopped using it.
Screenshot here: pineda.no/images/products/srecopy2_04.gif

we hav this type of freeware in france...

Screeshot : http://supercopier.sfxteam.org/uploads/scdeplier.png

Web : http://supercopier.sfxteam.org/modules/news/index.php?sel_lang=english

Download : http://supercopier.sfxteam.org/modules/mydownloads/

[quote]http://www.pineda.no/products/securecopy/
I tried this a while ago, but occasionally it would corrupt my files so I stopped using it.[/quote]
It's possible there's a bug in the SecureCopy program which caused your corruption but if you've got a VIA-chipset motherboard it might be worth ensuring you have the latest drivers.

I've got a friend who experienced occasional corruption when copying in Opus which turned out to be a bug in VIA's IDE bus mastering drivers (from memory) where the increased graphics operations (due to all the information shown in Opus's progress dialog) was triggering the problem.

Once the VIA drivers were updated the problem went away. It's a general problem with some versions of VIA's hardware/drivers rather than something specific to Opus. Other programs and operations can trigger the same problem (I've seen reports of it from people who don't have Opus) but Opus seemed to trigger the problem more than Explorer did, presumably due to the progress dialog. Since the SecureCopy program shown above also has a lot more going on in its progress dialog I figured it could be the same sort of thing. (Of course, it could simply be a bug in the SecureCopy program.)

Oops, I didn't read the original post well enough the first time.

This is not as simple as you might think. Think of logical disks, NTFS volumes mounted on a directory rather than on a drive letter, or even worse: remote drives. Besides, in case of congested networks you might even want to queue the operations even if you are copying to different (remote) drives.

-Caine.

Personally, I think such functionality should have only very basic options that put the onus on the user to control the queueing:

  • make a global Preferences->File Operations option to Queue all copy/move operations
  • make a new explicit argument for internal functions like Copy such as ADDTOQUEUE

From there users can create separate drop actions for 'normal' copy or 'queued' copy, and I would hope to see an extension made to the copy/move progress dialog that could let you shift the priorities of queued operations, as well as to 'run now' in cases where you know the operation involves different drives and you've enabled the kind of global 'queue' option mentioned above...

Interesting. It was a while ago, but I was getting the corruption on a via-chipset mobo (a K8T800). I might have another crack at it sometime. Or just wait until GPSoft incorporates this functionality into dopus :slight_smile:

That's a good point. Although I assume there would be some way of resolving particular copy source/destinations to their physical disks in windows, after all, Disk Management does this. I suppose there could be an option to disable automatic queueing for network copies as well. But yeah, this functionality is secondary to the manual queueing in my mind. If I can specify which transfers get queued, and them move individual files or groups of files up and down a queue list, that would be close to perfect.

I think I agree with you here. The auto-queueing thing might be nice, but would probably get too complicated and hard to fit to everyone's preferences.

One thing I though might be nice is the ability to kind of 'dock' a copy progress dialog with another one, and have the two dialogs kind or merge themselves together, so the first dialog's files would be put at the end of the other dialog's queue. There would also be a hotspot (or something) in the merged dialog that you could drag out and un-merge them again if you subsequently decided you didn't want them queued any more.

One potential problem I can see with the "Queue all copy/move operations" option would be that sometimes I would want to have two parallel copies going on. Eg: CD-ROM > C: and D: > E:

-Sam.

SuperCopier looks pretty cool (there's an english translation too). Is there any way to get it to work with Dopus?
I added dopus.exe to its list of handled processes, but that doesn't seem to work (unsurprisingly).

Yeah, someboy has posted my favourite request again! The Copy queue!

PLEASE! PLEASE! PLEASE! Implement this!

I don't think every action should be put into a queue. The should be a a way to intentionally queue copy operations (like the ADDTOQUEUE suggestion) and an "intelligent" mode that automatically enqueues a requested copy operation if either the source OR target DRIVE (not the partition since only checking this is useless) is already participating in an active copy/move operation. This intelligent mode would prohibit the performance drop that occurs when doing parallel copy operations.

I have to say Total Commander has this function for a long time.

Oh - well that should make it easier to get it added into Opus... LOL.