Perform a search in a folder included in a library.
From the search results collection, drag and drop some files to another folder in the same library.
The files are copied, instead of moved.
How to reproduce:
(hypothesis : of course all the libraries and folders here are on the same physical partition)
In the explorer mode, go into a library (for instance My Music ; it may even be a folder in a library, like Documents / My Music).
Press Ctrl F, run a DOpus search that will give you some files as a result.
The files are in the Search Results collection – the tab appears / is focused with the search results.
Select some files, then drag and drop them in the folder tree to My Images library – or to the Documents / My Images folder in a library.
Look in that folder : the files are there ; but look in the original folder where they came from : they are there, too. So now they are duplicated.
I would add another facet to probably the same problem: when you cut – paste from a collection to a physical folder on the same partition, the files are copied instead of moved, which makes the process slower.
I can reproduce the first post, but I can't reproduce the 2nd post.
i.e. For me:
Moving from collection to library does a copy-then-delete instead of a rename.
Moving from collection to a real folder does a rename, if the target folder is on the same drive.
Yes, that's the problem, the copy-then-delete is a lot slower than moving the files
Well, it looks like it depends on how the file arrived in the collection: if you got it there from a collection library, then it will be copied to the folder. If you got it there from a physical folder, the behaviour is normal, as you said.
Well, I have a 350 MB file in the Documents/Outlook library/subfolder (Documents points to D:\Data\Documents). To make things simpler and different from the first post, I just drag and drop it to an existing collection, i.e. the Search results.
Go to the collection, select the file and press Ctrl X. Then go to the physical folder D:\Data\Documents. Press Ctrl V. The file copy progress bar appears and it takes some time to put the file there. This is the problem here.
Then empty the collection, go to the physical folder D:\Data\Documents\Outlook, drag and drop it again in the same collection, then go to the collection again, select the file and press Ctrl X. Then go to the physical folder D:\Data\Documents. Press Ctrl V. The file is moved instantly and this is how it’s supposed to behave.
The next update isn't released yet, but I might have found another bug that might come from the same problem that we discovered above: it looks like there is a hidden "origin" field in collections that is not always used as it should...
If I run a MS-DOS batch on files from a collection and if they arrived there from a library (drag & drop, copy - paste, etc.), the MS-DOS batch would interpret {filepath} codes as "lib://..." And the MS-DOS doesn't understand that! If the files arrived in a collection from a physical folder or from a search, then the {filepath} codes are interpreted as the physical path, which the command line understands.
Could you please check if this is fixed in the next release, too?
And if it's a different bug, I could put it as another post here in the forum.
It looks that the above mentioned problems are fixed in 10.0.4.1, thank you! But there is another aspect this version didn't solve:
When you use Copy Full Path (in the Edit menu) on a file in a collection, it would either give you the real folder path or the lib:// path, depending on how it was inserted in the collection (as I described above).
Now if you use this path from the clipboard into another piece of software, it won't recognize lib:// It will work only in DOpus.
So, in my opinion, the Clipboard COPYNAMES=unc should have the same behaviour regardless of how the file got there.
Hopefully there will be a fix for this in the next version.