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 1978]

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 1978]

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 yesterday at 08:52 PM by Anders Melander

[Anders Melander 1978]

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 1978]

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 !

 

[Anders Melander 1978]

2 hours ago, Mustafa E. Korkmaz said:

These programs can do copy-paste file transfers. Also, open source rustdesk can do it. I'll look at the source code

I'm apparently not getting the message through; There is nothing special required, by neither the source nor the destination, in order to support copy/paste of files via RDP. The RDP support is transparent.

 

If your remote application copies data onto the clipboard in the FileContents & FileGroupDescriptor formats, then the local destination will be able to paste it.

 

Waitamoment.. I just realized that you just used remote desktop as an example. You will not actually be using remote desktop. Is that correct?

So you are actually just asking how remote desktop makes the remote clipboard available to the client and how to replicate that functionality in your own client/server system.

 

Well, I don't know the exact details of how it's done but I know enough about the clipboard and dragdrop that I can guess.

• On the server, the RDP host monitors the clipboard (there's an API for that).
• When data is copied onto the clipboard, in one of the formats supported by RDP, the server sends a message to the client with the meta data (data formats, size, etc.) of the clipboard data.
• On the client, the RDP client receives the message and copies the (meta) data onto the local clipboard using an IDataObject interface.
• On the client, some application pastes from the clipboard...
• The local clipboard asks the local data source, via the IDataObject interface, for the data.
• The local RDP receives the data request on its IDataObject interface and forwards this request to the remote RDP server.
• The remote RDP server in turn does the same: It asks the remote clipboard for the data, the remote clipboard asks the remote data source (whoever copied the data onto the clipboard in the first place), etc.
• Once the remote RDP server has the data it sends it back to the local RDP client which then supplies it, through the IDataObject, to the local application.
• Done. Paste complete.

 

A normal paste can cause data to be sent back, through IDataObject, notifying the source about the paste. I don't know if RDP propagates this information all the way back to the server.

[Mustafa E. Korkmaz 1]

There's no way to find out which location the paste option was selected from, but there was no need for that anyway.

2 hours ago, Anders Melander said:

The local clipboard asks the local data source, via the IDataObject interface, for the data.

I didn't know how to do this. I learned after a couple of tough tries.

2 hours ago, Anders Melander said:

• The local clipboard asks the local data source, via the IDataObject interface, for the data.
• The local RDP receives the data request on its IDataObject interface and forwards this request to the remote RDP server.
• The remote RDP server in turn does the same: It asks the remote clipboard for the data, the remote clipboard asks the remote data source (whoever copied the data onto the clipboard in the first place), etc.
• Once the remote RDP server has the data it sends it back to the local RDP client which then supplies it, through the IDataObject, to the local application.
• Done. Paste complete.

Yes, that's exactly how it works. Thank you Anders.

 

I have developed a demo. I am sending the VirtualFileDataObject.pas unit as an attachment.

 

The TVirtualFileDataObject.GetData and TGeneratedRandomStream.Read parts are important.

When you press the button, it copies the virtual file to the clipboard.
When you select the paste option anywhere in Explorer, the TGeneratedRandomStream.Read section starts to be called by Explorer.
This function ends when we give the result value 0.
It creates a random 10 KB stream 7 times and gives it to Explorer. At the end of the process, a file named 'RandomData.bin' is created.

 

uses

 ActiveX, VirtualFileDataObject;

 

.......

 

procedure TForm1.Button1Click(Sender: TObject);
var
  DataObj: IDataObject;
begin
  DataObj := TVirtualFileDataObject.Create;
  OleSetClipboard(DataObj);
  ShowMessage('The virtual file has been copied to the clipboard. Try pasting it in Explorer.');
end;

 

VirtualFileDataObject.pas

[Anders Melander 1978]

Looks good. You're leaking the TGeneratedRandomStream object though.