The COPY queue was used to be bypassed when a MOVE was being done within the same drive. This is no longer the case and a MOVE within the same drive that takes a fraction of a second, is queue like a COPY.
Is there a way to re-instate the so useful bypass-queue-for-MOVE-within-same-drive?
Thank you and keep up the work on this amazing piece of SW-art!
George
I'm not sure that has changed, at least not recently. We did recently change the queueing rules for folders on drive mounts (if I remember correctly) and possibly network drives (I'd have to check if that change has gone out yet) which could account for what you're seeing, depending on the types of drives involved.
@Leo it was pretty recently, though not sure it was in the last update (12.26 x64) or the one before. My case is that I use plenty of network drives. Before, copying was queued and any same-drive-moving was run instantly, which was great. Now, any moving (same drive) is queued too.
Thanks in advance for you checking it!
George
@Leo after a few updates (new versions of your fine SW!) and the files to MOVE are still being queued, waiting for the COPY-files-queue to be completed for getting their turn. Have you checked this? Will you reinstate the MOVE-files to be immediately processed (as it was in the past Dopus versions) and not being queued along the COPY-files? Thank you.
Were they really? I don't think they were, but I am not sure. I do remember having used this Run now button more than once. Useful feature, definitely!
I could do some tests with previous versions to find out if anything changed for sure. Would need to know:
Approximately which version the changes started with.
(List of versions and dates here. Easy to work out if you installed all stable/beta releases. Otherwise may take some memory. I can go back a few more versions when testing to be sure.)
Exact steps to see the changed behavior. For example:
(Maybe those are already the right steps, but I want to make sure I test the right thing.)
@Leo the initial post of mine (in this thread, on top) is dated 16 DEC 2021, so I guess the files-operations-queue started processing same-drive-MOVE-files/folders as of v12.26 (2 DEC 2021) or v12.25 (29 SEP 2021).
In past versions, copying from/to the SAME network drive was queuing files/folders (as it should, since copying takes time) BUT moving was always being processed on the spot, without any queuing (moving files within the same drive = practically zero process time)
To replicate,
I hope this will help to figure it out and apply a hotfix! Thank you.
I tried with both 12.21 and 12.24 and they seem to behave the same as current version:
Looking through the change history, the only relevant thing I could find around the right time period was a change involving drive letters created by the subst command which both point at the same drive. In the past, they would not have been recognised as the same drive, but now they are. So if you're using subst to point multiple letters at the same drive (or its subfolders) that may explain why there's a change, but other than that I couldn't find anything.
If this may help, I have a few drive letters (4) pointing to the same network drive but to different path (folder) each one. This mapping was done from within Dopus (tools/map network drive) and not manually by any external command ("subst").
Your video was helpful and I got reminded of the queuing options menu:
which I have reactivated from within the "settings/preferences/miscellaneous":
It's been a long time that i have not used this confirmation pop-up since I had disabled it ("Don't show this message again") with the COPY commands being queued while the same-drive-MOVE-commands were running immediately. At some point before initiating this thread (DEC 2021) this was lost and apologies but I wish I could be more helpful with the exact version that this has occurred.
Currently, same-drive-MOVE-commands can be run on the spot only manually, either via the "Run-now" button of the confirmation pop-up:
or via the "play" icon from within the queue:
I tried the "Don't show confirmation again for this queue" + "Run Now" button, hoping that Dopus will retain this setting for the given queue. The first same-drive-MOVE-command is processed immediately but any subsequent same-drive-MOVE-command is queued.
Any way to automatically bypass the queue for same-drive-MOVE-commands please?
Thank you.
This wasn't mentioned before. Do I need to re-do all my tests? If so, please provide details of the mappings and shares involved.
It's not always possible to tell if two different shares on a machine point to the same drive or not (from the other side of the network), which can complicate things.
The queue confirmation settings just change whether the message is displayed or the item is queued silently. If you want to bypass the queue always/explicitly, you can do that by editing the Move button (or having a special Move button for when you want to do that). Or just turn off automatic queueing entirely, if it's getting in the way.
@Leo no alarm for more testing since the case described has always been from/to the SAME drive-letter!
Since I work with both copying and moving files, using drag-and-drop, turning off auto-queuing will end-up in multiple parallel copy processes. How do you advice I may bypass the queue for same-drive-letter-MOVE-processes, for drag-and-drop operation?
A script add-in that handles the OnGetCopyQueueName event could also do this; it could check for a move operation and compare the paths, and return True to run the operation immediately if desired.
@Hardkorn
Worked like a charm! Both the drag-and-drop plus the cut & paste (ctrl-v)!
!!! Respect !!!
