Move treated as Copy by Copy Queue logic

If I start a long copy operation from say D:\ to E:\ and then drag a file from one folder to another on the same partition (Mouse cursor indicates a Move, which is correct), the copy queue dialog is displayed saying it has been queued. If I look at the queue, it says Copy instead of Move.

This means that the Move operation is not automatically carried out (as you previously implemented per my request Improve Copy Queue logic for Moves when src/dest same).

If I manually run the queued item, the Undo log shows it correctly as a Move.

So, the bug us that the Copy Queue logic is seeing the Move operation as a Copy operation.

Running latest 11.7.4 x64 beta

A move from one partition to another partition is correctly identified as a Move by the Copy Queue logic

I cannot reproduce this. I start a copy from D:\ -> C:, then drag a file from C:\ to C:\ to move it, and the second operation is correctly queued as a move.

Are you confusing the window title at the top of the progress dialog with anything to do with the queued operations? The progress dialog title tells you what the current opreation is doing. You can expand the queue to list the later operations, and should see Move down there.

When I say it sees it as a move, I mean that if I queue the operation and expand the queue list, it's has "Copy" on the left of the queued item (near the mini buttons to start immediately and delete the queued item)

Try doing D: to D: (ie. move is same partition as source of first copy). Full details of what I did...

  1. Start long copy from D: to E: (D: is removable, E: is not. both are on physically different disks)
  2. Start copy from D: to D: (note it's same as source in (1), and as mentioned in (1) it's removable)

Win 8.1.1 x64 in case that makes a difference.

Plus, if the item is being queued in your test, that is incorrect, as you changed that behaviour to always perform a Move immediately since a Move does not really contribute to disk thrashing (see link in first post for more details).

Do you actually have the NOQUEUEWHENSAME argument set in your drag & drop event?

No

That's probably why then :slight_smile:

But Leo changed Opus so that all moves will be done immediately, irrespective of whether a copy is already in progress. See link in my first post for more details.

Plus as per screenshot, why is a move being listed as a copy when the source and dest partitions are the same ? This is the reason a move operation is being queued in the first place, as it sees it as a copy instead, so the change that Leo made does not come into play.


In the thread you keep referring to, Leo said:

And that "something" was, as per the release notes:

You said at the time you could confirm that it worked so presumably you modified your command at the time, and somehow it got changed back.

When I confirmed that it fixed the issue, I never changed anything (apart from upgrade to the newer beta), and I haven't touched that command since either. Would the upgrade (install over top of old version) have changed it so Copy NOQUEUEWHENSAME was the default ?

In the thread I referred to, Leo said

in reply to someone who said

I took this to mean that Leo understood that ALL moves will/should not be queued if the source and dest partitions of the move paths are the same, and had made a change. I suppose Leo can chime in later with what he actually meant. :slight_smile:

That aside, why is a move listed as a copy in my screenshot ? This is why I think the move is being queued, as Opus thinks it's a copy. I could be wrong though.

What does your drag and drop event run?

Which folders are you dragging between?

"All files and folders" file type drag-and-drop event is set to "Copy movewhensame".

For the above screenshot example, the folder "D_Backup" was being copied (ie. left-click drag-and-drop with no modifier) from G:\ to D:, and then I moved TODO.txt from G:\ to G:\Corsair (again, left-click drag-and-drop with no modifier). NOTE: G: was a Truecrypt mounted removable volume. D: was a fixed disk volume on a separate disk from G:.

Thanks!

We've reproduced that, and a fix is on the way.

It looks like the label in the queue list has always been "copy" for Copy MoveWhenSame, FWIW. (My main machine uses Copy Move which is why I did not see the same thing at first.)

Only the label was wrong, not the operation performed, so if you still want the changed behaviour discussed in the other thread, you will still need to add the NOQUEUEWHENSAME and/or CUTNOCOPYQUEUEWHENSAME arguments Jon mentioned.

OK, thanks. I've just done some further testing and noticed that if I start a copy job where source and dest are both fixed disks, then move from source to source, the move IS performed immediately with the command "Copy movewhensame" (ie. without NOQUEUEWHENSAME and/or CUTNOCOPYQUEUEWHENSAME).

The only difference from the other tests is that this time the source was a fixed disk.

Is this a bug then (ie. it should only work with NOQUEUEWHENSAME and/or CUTNOCOPYQUEUEWHENSAME), or expected behaviour (ie. because it's not a removable disk) ?

That would only happen if the existing copy had a different destination to the drive you were moving on (assuming we are talking about automatic queueing).

Automatic queuing is based on the destination drive.