Bug report: moving from the results collection to a library

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)

  1. 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).
  2. Press Ctrl F, run a DOpus search that will give you some files as a result.
  3. The files are in the Search Results collection – the tab appears / is focused with the search results.
  4. 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.
  5. 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.

Not sure what you mean. Files in collections don't remember how they were added to the collection; they just point at wherever the real file is.

Can you give some steps to reproduce the collection version of the problem?

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.

Ah, okay, the collection is pointing at the library, not at the real location. i.e. "if you got it there from a library" rather than collection.

I think I can repro that. Thanks!

We think all these are now fixed for the next update (but please let us know if you spot any remaining problems once the update is out, of course).

This is good news!

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...

I discovered this while debugging some MS-DOS batch buttons (View the MS-DOS Batch command created).

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.

This might be another symptom: I can't copy / move files from the duplicate collection to the folder tree. DOpus constantly finds an error.

Please wait for the 10.0.4.1-beta update before reporting/testing related issues, as it's likely they are all fixed already.

Once it is out, if there are any remaining issues then we can look at them then and get them fixed quickly in a follow-up beta version.

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.

We'll get the clipboard thing fixed for 10.0.4.2.