Capture as soon as file paste is selected

[Mustafa E. Korkmaz 1]

Is there a way to detect when someone right clicks on a folder and tries to paste?

If the copy option is selected for any file. Then, when the paste option is selected in a different folder, can we find out from our program which directory the paste operation was made to?

 

For example, how do remote desktop applications do this?

You copy any file from the remote computer with the windows copy option. The file transfer starts as soon as you say paste to any location on your own computer. It is easy to find out which file was copied from the remote computer.

However, when paste is selected in any directory of the operating system, it is difficult to both catch the paste event and find out in which location the paste was said.

[Anders Melander 1977]

53 minutes ago, Mustafa E. Korkmaz said:

Is there a way to detect when someone right clicks on a folder and tries to paste?

Unless your application is the source of the clipboard data, then I don't believe it is possible.

 

 

56 minutes ago, Mustafa E. Korkmaz said:

can we find out from our program which directory the paste operation was made to?

TLDR; No

The destination might not even be a directory. It could be anything since it's completely up to the target what it does with the data.

 

59 minutes ago, Mustafa E. Korkmaz said:

how do remote desktop applications do this?

My guess is that the remote desktop client monitors the local clipboard for supported formats. When data is copied onto the clipboard it pastes copies of the data onto the remote clipboard.

In the case of files/folders, the actual transfer of the files are only done, on demand, if an application reads data from the remote clipboard. This last part isn't specific to RDP; The same thing happens when copy/pasting on a local system.

 

1 hour ago, Mustafa E. Korkmaz said:

it is difficult to both catch the paste event

That part is easy because the system asks the source for data when it is needed - i.e. when it is pasted.

 

I suggest you experiment with all this using the Drop Source Analyzer and Drop Target Analyzer tools that are part of the Drag and Drop Component Suite (drag and drop and the clipboard are the same thing, in case you wondered). This will give you a better understanding of how the clipboard works internally.

 

Here's what a clipboard copy/paste from the target to the source analyzer looks like:

 

Unfortunately you can't use the target analyzer with remote desktop because it doesn't put the file formats onto the clipboard that remote desktop supports. You can use it see remote desktop asking for data though.

I can probably modify it to add the required formats if there's demand.

[Rollo62 571]

Interesting question.

Feasibility with Hooks:

- Key Hooks (WH_KEYBOARD_LL): These are irrelevant for detecting paste operations, as pasting is typically triggered via mouse or context menu, not keyboard shortcuts.
- Global Mouse Hooks: These can detect right-clicks but cannot reliably identify the "Paste" command or the target directory.
- Shell Hooks (HSHELL_*): Using SetWindowsHookEx with WH_SHELL or registering for Shell notifications (SHChangeNotifyRegister) might provide some context about Explorer actions,
   but they do not directly expose paste events or destinations.

Alternative Approaches:

- Windows Shell Extensions: Create a Shell Extension (e.g., a context menu handler) to intercept paste commands in Explorer. This requires injecting code into Explorer’s process,
   which is complex and may have security implications.
   Maybe that could work for you, although it interferes too much with Windows systems for my taste.

[Kas Ob. 135]

1 hour ago, Mustafa E. Korkmaz said:

Is there a way to detect when someone right clicks on a folder and tries to paste?

Yes.

1 hour ago, Mustafa E. Korkmaz said:

can we find out from our program which directory the paste operation was made to?

Yes.

1 hour ago, Mustafa E. Korkmaz said:

how do remote desktop applications do this?

In two different way, one when to upload and one to download, but this is somehow irrelevant to your usage, as like Windows RDP it comes baked with special integration with for Windows Explorer aka Windows Shell, these are undocumented API and COM objects.

 

 

How to do it ?

You must understand and use these :

1) IFileOperation https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifileoperation this will capture (and monitor) copying files, moving ,renaming ....

2) IFolderView https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifolderview to find the focused folder in Windows Explorer

3) SHChangeNotifyRegister for hooking shell operation https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shchangenotifyregister

4) IShellWindows https://learn.microsoft.com/en-us/windows/win32/api/exdisp/nn-exdisp-ishellwindows this is the core one to start with and needed to find opened folders ..etc

 

Using these will remove the need for key logger and mouse tracking event, yet in case it failed or and because i can't remember how the hooking was triggered as only reporting or intercepting, meaning you can block, in case that the case and you need to prevent the operation, then you will need key and mouse logger, there is few methods to intercept then cancel if you want.

 

Hope that help, as for all the above, there is many questions on the internet and resources on how to do it, but you specific case need to understand and mix and match an approach.

[Mustafa E. Korkmaz 1]

13 minutes ago, Anders Melander said:

My guess is that the remote desktop client monitors the local clipboard for supported formats. When data is copied onto the clipboard it pastes copies of the data onto the remote clipboard.

In the case of files/folders, the actual transfer of the files are only done, on demand, if an application reads data from the remote clipboard. This last part isn't specific to RDP; The same thing happens when copy/pasting on a local system.

 

13 minutes ago, Anders Melander said:

That part is easy because the system asks the source for data when it is needed - i.e. when it is pasted.

 

I connected to the remote desktop. I right-clicked on the 4 GB file on the remote computer's desktop and selected copy. 
Then I right-clicked on my desktop and selected paste. Or not on the desktop, right click on any directory in file explorer and paste it.
As soon as I selected paste on my desktop, the file transfer started.

 

I want to do the same thing as they do.

 

I think it should be something like this: When copying from the remote computer, my program will write something to the local clipboard. When paste is selected in the file explorer, a call will come to my program again.

 

 

[Anders Melander 1977]

6 hours ago, Mustafa E. Korkmaz said:

I connected to the remote desktop. I right-clicked on the 4 GB file on the remote computer's desktop and selected copy. 
Then I right-clicked on my desktop and selected paste. Or not on the desktop, right click on any directory in file explorer and paste it.
As soon as I selected paste on my desktop, the file transfer started.

Okay. That is the opposite direction of what I thought you wanted to do but never mind; The same rules apply.

 

6 hours ago, Mustafa E. Korkmaz said:

I want to do the same thing as they do.

They are not really doing anything special. The remote desktop server monitors the remote clipboard. When data is copied onto the clipboard the RDP server notifies the RDP client which then pastes the data onto the local clipboard. Note though that the actual data isn't transferred unto the local clipboard until someone pastes it or the data source is closed (this is normal clipboard behavior and has nothing to do with RDP). Only the meta data is transferred immediately.

 

This is what a paste of a copied file from RDP looks like:

 

Note that even though I copied a file, the normal CF_HDROP (which would contain a filename) isn't there. Only FileContent (the content of the file) and FileGroupDescriptor (the file meta data) is made available. The remaining data are just 3 DWORD flags that aren't relevant to this.

 

6 hours ago, Mustafa E. Korkmaz said:

When copying from the remote computer, my program will write something to the local clipboard. When paste is selected in the file explorer, a call will come to my program again.

It's a bit hard to understand what you are doing since I don't know where "my program" is running or where "the file explorer" is running.

 

My guess is that "my program" is running on the remote system and "explorer" on the local. In that case what you want is what I call a virtual drop source (remember: dragdrop and clipboard, same thing). The library I linked earlier has multiple examples of that; The source (your application) supplies the filename(s) of the data to be transferred (dragged or copied to clipboard) and when the target reads the data (from a drop or from the clipboard) then the source is called to supply the actual file content.

See: Transferring Data to and from Virtual Folders

Edited 15 hours ago by Anders Melander

[Anders Melander 1977]

6 hours ago, Kas Ob. said:

How to do it ?

You must understand and use these

Seriously?

 

That solution is at best a hack and there are a thousand ways it could break. There is a reason why Microsoft hasn't provided us with a way to determine the target of a drop or a clipboard operation (CFSTR_TARGETCLSID being the exception). Maybe it would be best to not try and circumvent that?

[Mustafa E. Korkmaz 1]

10 hours ago, Anders Melander said:

They are not really doing anything special. The remote desktop server monitors the remote clipboard. When data is copied onto the clipboard the RDP server notifies the RDP client which then pastes the data onto the local clipboard. Note though that the actual data isn't transferred unto the local clipboard until someone pastes it or the data source is closed (this is normal clipboard behavior and has nothing to do with RDP). Only the meta data is transferred immediately.

 

There's no problem with that part. I agree with you. 

 

10 hours ago, Anders Melander said:

Then I right-clicked on my desktop and selected paste. Or not on the desktop, right click on any directory in file explorer and paste it.
As soon as I selected paste on my desktop, the file transfer started.

How will my program detect when right click paste is selected anywhere in the Windows operating system? This is the part that cannot be solved.

"my program" :   My client program running on local computer.

 

My server program running on remote computer.

My client program running on local computer. Right click paste operation is performed anywhere in the Windows operating system on the local computer.

 

When paste is selected anywhere in the Windows operating system, our program running on the same computer will detect this. And it will know under which directory paste is requested.
Not only the Windows remote desktop application but also applications such as Anydesk, TeamViewer etc. can do this.

 

[Anders Melander 1977]

3 minutes ago, Mustafa E. Korkmaz said:

When paste is selected anywhere in the Windows operating system, our program running on the same computer will detect this.

This isn't possible. Only the data source is notified when data is pasted - and it isn't actually notified of a paste but it can deduce that a paste is happening because it is being asked to supply the data being pasted.

 

4 minutes ago, Mustafa E. Korkmaz said:

And it will know under which directory paste is requested.

Also not possible. Only the data target knows the destination of the data. The fact that a paste in Explorer happens to write something to disk somewhere is an implementation detail that is entirely internal to Explorer. There no rule that says that a file being pasted somewhere has to go to disk. The destination could be a virtual device that ends up printing the file in hex onto toilet paper and mailing by pigeon it to the nearest Buddhist temple. How would Explorer communicate that to anyone?

 

5 minutes ago, Mustafa E. Korkmaz said:

Not only the Windows remote desktop application but also applications such as Anydesk, TeamViewer etc. can do this.

I disagree. What makes you come to the conclusion that they do it?

 

Actually, maybe you should explain what problem you are trying to solve. Why do you need to know where a file was pasted?

[Mustafa E. Korkmaz 1]

24 minutes ago, Anders Melander said:

I disagree. What makes you come to the conclusion that they do it?

These programs can do copy-paste file transfers. Also, open source rustdesk can do it. I'll look at the source code
https://www.youtube.com/watch?v=KiGcYqvR-pM

[Kas Ob. 135]

13 hours ago, Anders Melander said:

Seriously?

 

That solution is at best a hack and there are a thousand ways it could break. There is a reason why Microsoft hasn't provided us with a way to determine the target of a drop or a clipboard operation (CFSTR_TARGETCLSID being the exception). Maybe it would be best to not try and circumvent that?

Hi Anders, 

 

I want to list some facts 

1) Windows Explorer is an application like any other, and it is not essential to the OS itself, so when RDP application run it will interact between two application, hence the need to capture and handle the clipboard, when i copy a file/dir form my own desktop and try to paste it on remote using RDP, then i am pasting the on my application (or RDP), and this should trigger RDP or on the remote to paste, so it should simulate clipboard is filled then send data.

2) CFSTR_TARGETCLSID is irrelevant here as it used internally by Explorer itself.

3) Microsoft RDP does send file in two different ways, one capturing clipboard and its content then simulate on the other hand, well usually it does that, unless Local resources being shared per setting in the RDP connection, this initiate completely different path to share files and synchronize them between host and guest.

4) SHChangeNotifyRegister can capture files changes and many others like copy and paste or rename, initiated by keyboard and/or by mouse. ( might not be useful or needed after all)

5) Th trick is to capture the event then using IShellExplorer to emulate pasting file in the specified directory, (also might be not needed at all)

 

So in short the solution is not to circumvent any thing, not really, because , as example, i built a RDP application, then on the remote part capture the copy event from clipboard (yes using clipboard APIs), then trigger filling the clipboard on my local PC, then on paste on my local i will initiate the sending file after locking the directory same as RDP (this locking will need shell APIs), same can happen in the other way around.

 

Now sounding this loud, i don't understand the need for monitoring the shell operation using SHChangeNotifyRegister ! may be i lost it there or over complicate things, but the copy and paste is happening into different applications, either my remote RDP with the remote Explorer, or local RDP viewer and local Explorer, sending data is handled by the RDP two parts not involving any Explorer.

 

 

ps: I spent near 3 hours trying to make SHChangeNotification_Lock work, but i think it is working at last !