Can a file copy be detected on windows? - windows

I want to trigger a piece of code to run as soon as a 'copy' command is executed on Windows. Let's say I want to perform some operations as soon as the user tries to copy a file. Is there any way to detect the 'copy' operation on Windows?

You may monitor the clipboard (see Creating a Clipboard Format Listener) and check if there is an object with format CF_HDROP in it. But it will not tell you when the clipboard paste operation actually started.
This also will not cover copying which does not involve clipboard, like direct file_read/file_write loop in a File Manager application. For this you may monitor changes in the file system (see How can I monitor a Windows directory for changes?) but it will not tell you where was the file copied from, just where was it pasted to.

Related

Windows - Opening a file from code and wait for it to be closed

I need some help and/or advice please.
I'm opening a file from code in either the default associated windows program or with a selected windows program using either ShellExecute or CreateProcess. I then wait for the process to complete. But this does not really work for me because:
Let's say the default associated program for text files (*.txt) is Notepad ++ (NPP). For the process to complete, NPP must not be open to start with and must be closed to complete the process.
But if NPP is already open, the file will be opened in the already opened NPP. But I do not necessarily want to close NPP to complete the process, I just want to close the opened text file and need to detect that the file has been closed and not NPP.
So I realised that waiting for the process to complete is not going to work. I've tried several things like trying to detect if the if the file is opened in another process but have not had any success.
So my question is, what would be the best method to detect when a file is open or in use and vice versa?
It sounds like you want to know when the file handle is "closed", not necessiarly when the program that operated on that file has exited.
Your question is closely related to this question. You could reference that to periodically poll the process handle to see what files are open. There will be timing issues - it might take a few seconds for the process to open the file in the first place.
There are also tools such as Handle.exe that may be useful.
However - none of these solutions are perfect. Some apps, including Notepad.exe, just open the file, read the contents, and immediately close the handle. When the user clicks "save", the file is re-opened for writing, contents saved back to disk, then the file handle is closed again.
A simpler approach would be to periodically poll the last-modified timestamp on the file via GetFileTime. When it changes, you could assume the file has been "Saved". Or apply this technique with some combination of the above and/or waiting for the application that was launched to exit.

How to manage files with a batchscript via "Send To"?

I want to improve my file managent and need some help to get started.
For this specific script, my idea is the following:
while in Explorer
rightclick a file -> Send To -> "Apps[.bat]"
Then the script starts and does the following:
moves the whole directory (and subfolders) of the selected file to a specified location (in my case C:\Users\Name\Desktop\Apps\Files)
so sending Name\Downloads\Coolportableapplication\Coolapp.exe to the batch results in Name\Desktop\Apps\Files\Coolportableapplication\Coolapp.exe
creates a shortcut of C:\Users\Name\Desktop\Apps\Files\Coolportableapplication\Coolapp.exe in C:\Users\Name\Desktop\Apps
Is this generally possible with a batchscript?
This isn't my first batch but I've never dealt with unspecified files and English isn't my native language so I couldn't really find anything useful for my cause, though I am sure my little script won't be too much of a problem for you. Based on that batch, I want to create similar scripts but I just have no idea how to begin with that one.
Thanks a lot!
No need for a batch file but anyway.
1: Type shell:sendto into your explorer window and copy the shortcut to your directory "C:\Users\Name\Desktop\Apps\Files". This directory will now show as default in your Send To options.

Windows Explorer and Reparse Point Files: keep Explorer from opening my files

I've implemented a user mode program and a Windows file system minifilter that creates a skeleton view of users files for a remote file storage system. It maps the remote files to the local drive. The user mode program creates a reparse tag for each file on the remote system. When a create request (e.g., CreateFile for read) is detected, the minifilter asks the user mode program to download the file. This should only happen when a program wants to open the file for viewing or editing.
But, I'm finding that Windows Explorer is triggering my files to download. I'd like to prevent the Explorer File windows and File Open/Save dialogs from
triggering downloads. And, I also want to display the file thumbnails and file
size.
[Update: I've found I can use Windows sparse files to show my remote
file size in Explorer. ]
Therefore, I have also implemented a Shell Extension, IThumbnailProvider, that downloads a rendition of the file. This provides the file thumbnails.
For my testing, I've registered the IThumbnailProvider for all files (*) and for .jpg files.
I'm seeing two interesting behaviors using a combination of Process Monitor and DebugView (both from SysInternals):
1. If I make my minifilter reject requests to open the file from Explorer, then my IThumbnailProvider is invoked.
2. If I permit open requests from Explorer, I see thumbcache.dll in the call stack trying to open the file and my IThumbnailProvider is not called. It appears that the default thumbnail provider reads the downloaded file and creates the thumbnail.
I must be missing something.
Update: if I use InitializeWithStream instead of InitializeWithFile, it appears my handler is invoked. But, that also triggers a download of the file.
There are many shell extension types which can access to your files. Icon handler can read file to create icon, Info tip handler can read file to create text hint, Data object handler can read file to create clipboard data and so on.
Questions from developer with the same problem: first and second. Solution was to create namespace shell extension. NSE can control all access to your files.

How is "Cut" command in Windows executed globally and why data recovery is not possible?

So, I wondered several times, what's the actual low-level difference when using "Cut" command in Windows, apart from Copy-Paste-Delete one, with focus being on the "Delete" part.
However, until now it wasn't really important, but I had some issues recently when using Cut-Paste in my application, when having an error in the process. The file that was being Cut-Pasted doesn't exist anymore, and can't be recovered by any data recovery software out there.
So I ran some tests, and it seems that it's true.
Anybody knows how the Cut-Paste commant works?
The clipboard
Windows manages an internal object called The Clipboard and provides an interface to put data in the clipboard, get the data from the clipboard, get meta information about the content of the clipboard (check if it is empty or there is any data there, get the type of the data a.s.o.). The operations with the clipboard (get, put) have copy semantics. They do not destroy the source data. The object currently kept in the clipboard can be get from there any time you want, it is not removed after the first "get" operation.
The clipboard can store a single object at any time. When an application puts something in the clipboard the previous content of the clipboard is lost. The clipboard can store the same data in multiple formats; is the application's responsibility to put it there in multiple formats, to query about the available formats and get the data in the format it wants. For example, an HTML-editor can put in the clipboard both the HTML source code of the selected text and the text as it is rendered in the browser (with different colors and fonts etc). Then, the same application or another application either gets the needed format depending on the context or provides a "Paste Special" command where it asks the user what format to use (see Microsoft Office programs or OpenOffice programs for example).
The clipboard is available (through the operations provided by Windows) to all the applications that want to use it and it is a powerful method to transfer data between applications. However, due to different formats used by different applications, it is not always possible to get data from an application and put it into another one. For example, a plain text editor like Notepad cannot Paste an image previously put in the clipboard by Paint, Photoshop or another graphic editor. This happens because Notepad just don't know how to handle anything but plain text.
The Cut, Copy and Paste semantic for applications that handle content (text, images etc)
It's up to each application how they use the clipboard. Implementing the Cut, Copy and Paste operations usually means:
Cut - the application puts (copies) to the clipboard the object selected in the document then remove it from the document;
Copy - the application puts (copies) to the clipboard the object selected in the document (but it does not remove it from the document);
Paste - the application gets (copies) from the clipboard the object stored there and puts into the current document; depending on the application, it is either inserted at the position of the caret, or replaces the current selection or it is simply inserted into the current container (folder or directory, in Windows Explorer); the content of the clipboard is not changed; a subsequent Paste is possible and it will do the same;
The Cut, Copy and Paste semantic for applications that handle files (Windows Explorer, for example)
Windows Explorer and other programs that works with files and not with pieces of text or image use a different semantic. The biggest difference from the model above is that Windows Explorer works with file names (with full paths) and not with the content of those files. It does not reads the file and it does not place the content of the file in the clipboard.
Cut - Windows Explorer copies the full path of the file into the clipboard; it also sets an internal flag that says "the file whose path is in the clipboard is meant to be moved by the next Paste"; it uses this flag to be able to render the cut file dimmed in all its windows until the operation completes or is aborted; it does not move or remove the file at this point;
Copy - Windows Explorer copies the full path of the file into the clipboard; it does not touch the file itself; then it clears the flag that was set on the last Cut operation; the file that was previously cut (if any) is now rendered again using the same style as the other files (no dim, no nothing); in other words, a Copy cancels any previous Cut;
Paste - Windows Explorer gets the file path from the clipboard; it copies the file pointed by that path into the current directory; what it does after that depends on its internal flag for Cut operation; if the flag is set then the file was cut before (see Cut and Copy above) then it will remove the file from their original location and also the flag; otherwise (when the Cut flag is not set because the last operation was a Copy), it does not affect the original file in any way.
Remarks on Windows Explorer's behaviour
It's important to notice that Windows Explorer does not put the file content in the clipboard. If you use the Cut or Copy command in Explorer then you delete the file, it will not be able to Paste it in a different directory because the file does not exist any more and it cannot copy an object that does not exist.
Also, a file that was Cut in Windows Explorer cannot be Pasted multiple times in different directories because Explorer pairs the Cut with the first Paste (if there was no Copy in the meantime) and produces a move operations from them. After the Paste the Cut flag is removed and, even if it is not removed, there is no way to move the file again because it is not on the path stored in clipboard any more.
I'm not on Windows now (I didn't use Windows in the last 3 years) but as far as I remember, you can Copy a file once then Paste it several times; a Copy followed by a Paste produces a copy of the file and as long as the source is still there, subsequent Paste operations can produce more copies.
Sure, an error that happens on the most inconvenient moment can produce data loss. Due to the way Windows Explorer handles the files and the errors that might happen, it is very unlikely that it accidentally removes a file during a Cut-Paste operation without putting it into the destination folder.
I'm absolutely confident that more files are lost due to human error than because of errors that happen during the execution of Windows Explorer.
Other applications
Other applications work in different ways. Most of those that deal with content (text, image, sound, video, etc) work as explained in the section about content. Most of those that deal with files work similar with Windows Explorer.
Another application can get the data that was put in the clipboard but Windows Explorer. It's up to that application to interpret it as plain text and put the file path it gets from clipboard into the current document as is (Notepad works this way) or recognize it is a file path and attempt to copy the file (or do something else with it). Another window or instance of Explorer does it, maybe other file managers do it too.
Multiple-clipboard applications
The programs from the Microsoft Office Suite (Word, Excel a.s.o) and also some other applications implement a multiple-clipboard feature. This functionality is not provided by Windows clipboard. These applications work with the clipboard as usual but the also keep a history of the objects they put into the clipboard in the past and offer the user a list of these objects for re-use. For compatibility and integration with other applications they also get from and put into the clipboard the object that the user selects for re-use. The Windows clipboard, however, still contains a single object, the last one that was put there by any application.

Redirect default program to another program when a file opens in Windows OS

This is only under windows env.
As I know windows os identifies associated application of a particular file by file extension.
Like wise each file (binary) starting with corresponding symbols ("starting symbols"). For an example .JPG starts with ÿØÿà. Let say I open this .JPG file in a Hex editor or a Text editor and then I change that starting symbols into another file type. for an example I can change ÿØÿà to .Eߣ (.mkv). So when I double click on the .JPG the Windows Photo Viewer says there are some errors or similar message. So I need to get some information about the application that tries to open that kind of a file. If I can, I need to open that file using the application that associated with "starting symbols".
Briefly when I open .JPG I need to open a default video player .mkv files. But It may not work for this example. Because I changed only the "starting symbols" of my .JPG.
Please give me any idea to do this.
Thanks!
When you encrypt the file, give it a new extension. e.g. Picture.jpg becomes Picture.encrypted-jpg. You then register as the handler for encrypted-jpg, decrypt the file, then launch the normal jpg handler.
When the shell is asked to perform a verb on a file, the shell does not use the contents of the file to determine which app to pass it to. The file extension is what determines how the file will be treated.
You wish to use the contents of the file to influence which app processes a shell verb. In order to do so you would need to create a launcher app that reads the file header and then decides which app to pass the file on to. You would assign your launcher app as the handler app for all file extensions that you were interested in.
Although you could do this, it would be much easier just to set the file extension appropriately.
The proper way to do this sort of thing is to replace the files with reparse points.
The downside is that this involves writing a file system filter driver, i.e., an operating system extension, which is a whole level of trouble above and beyond ordinary application programming. (Since Windows already does file encryption, I doubt it would be worth the effort.)

Resources