After item is reactivated, pasting fails to rename a file copy in w10 Explorer

[sskras]

If I use Ctrl-C and Ctrl-V for eg. file AUTHORS in the w10 file explorer, the file gets pasted as AUTHORS - Copy. But if I activate a second item and then reactivate the first one before Ctrl-V, the pasting breaks.

Using vanilla setup of CopyQ, simply nothing happens. This has been addressed using different workarounds:

in #1192 ...

> ```ini > [Command] > Automatic=true > Icon=\xf0c1 > Input=text/uri-list > Name=Copy Files/URIs > ```

and in #1223 ...

\+ the [FAQ](https://copyq.readthedocs.io/en/latest/faq.html#how-to-reuse-file-paths-copied-from-a-file-manager): > ```ini > [Command] > Command=" > var originalFunction = global.clipboardFormatsToSave > global.clipboardFormatsToSave = function() { > return originalFunction().concat([ > mimeUriList, > 'x-special/gnome-copied-files', > 'application/x-kde-cutselection', > ]) > }" > Icon=\xf0c1 > IsScript=true > Name=Store File Manager Metadata > ```

Now if add any of these two and repeat the sequence, the first file gets pasted. But only if I go to a different folder containing no file with the same name.

When I stay in the same folder (where the original file resides) and press Ctrl-V, the copy isn't created. Instead I get following error in file explorer:

The source and destination file names are the same.

---

To Reproduce Steps to reproduce the behavior:

1. Use w10 desktop
2. Configure one of aforementioned workarounds
3. Go to the CopyQ folder using file explorer
4. Check if the manager is empty using MSYS2:

   $ cd 'C:\Program Files (x86)\CopyQ\'
   $ pwd
   /c/Program Files (x86)/CopyQ
   $ ./copyq count
   0

5. Click on AUTHORS file
6. Press Ctrl-C
7. Press F2, Ctrl-C, Esc (copy the file name only)
8. Check if there are two items in the manager:

   $ ./copyq count
   2

9. Select the original item (shown as 2 in the GUI but numbered as 1 in the CLI):

   $ ./copyq select 1

10. Go to the file explorer, press Ctrl-V
11. See error: The source and destination file names are the same.

---

Expected behavior

The AUTHORS files should get copied as AUTHORS - Copy in file explorer (as it happens before the item reactivation).

Screenshots

The error message:

Version, OS and Environment

CopyQ Clipboard Manager 6.3.2
Qt: 5.15.2
KNotifications: 5.92.0
Compiler: MSVC
Arch: x86_64-little_endian-llp64
OS: Windows 10 Version 2009

[sskras]

Additional context

By using InsideClipboard tool by Nirsoft mentioned in https://github.com/hluk/CopyQ/issues/1350#issuecomment-615219584 I see that native clipboard format on w10 looks quite different.

Attaching both .clp files and pasting appropriate tables from the tool (sorted by Index column):

• The original Clipboard content generated by file explorer

Format ID	Format Name	Handle Type	Size	Index
49486	Shell IDList Array	Memory	379	1
49746	DataObjectAttributes	Memory	12	2
49745	DataObjectAttributesRequiringElevation	Memory	12	3
49487	Shell Object Offsets	Memory	8	4
49495	Preferred DropEffect	Memory	4	5
49511	AsyncFlag	Memory	4	6
15	CF_HDROP	Memory	96	7
49158	FileName	Memory	26	8
49314	FileContents	Null	0	9
49159	FileNameW	Memory	74	10
49490	FileGroupDescriptorW	Memory	596	11

• The Clipboard content after item reactivation in CopyQ

Format ID	Format Name	Handle Type	Size	Index
13	CF_UNICODETEXT	Memory	90	1
1	CF_TEXT	Memory	48	2
15	CF_HDROP	Memory	96	3
49506	UniformResourceLocatorW	Memory	90	4
49499	UniformResourceLocator	Memory	44	5
49905	application/x-copyq-owner	Memory	17	6

[hluk]

It is possible that there is another channel (apart from the system clipboard) that communicates which action needs to happen in Explorer on Ctrl+V.

Otherwise in CopyQ you can check the available clipboard formats (with Ctrl+Shift+C or menu bar File - Show Clipboard Content) after copying from Explorer. If there are any formats that could affect the behavior, you can add them to the command from FAQ.

[sskras]

It is possible that there is another channel (apart from the system clipboard) that communicates which action needs to happen in Explorer on Ctrl+V.

Might be, but the Clipboardic v1.15 by the same Nirsoft restore the original action just fine: https://www.nirsoft.net/utils/clipboardic.html

Otherwise in CopyQ you can check the available clipboard formats (with Ctrl+Shift+C or menu bar File - Show Clipboard Content) after copying from Explorer. If there are any formats that could affect the behavior, you can add them to the command from FAQ.

Thanks, I got this idea for another issues. If I find the needed format that is missing, would it be possible to integrate it into the default setup so it works out-of-the-box ?

[hluk]

Thanks, I got this idea for another issues. If I find the needed format that is missing, would it be possible to integrate it into the default setup so it works out-of-the-box ?

I don't want to clutter the app with functionality that not many people use or is platform-dependent.

Better to add it to the FAQ entry. Feel free to create PR, otherwise let me know which format to add. Thanks.