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.
Related
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.
I am using Base SAS 9.4 on Windows 7. For various reasons, which are detailed below, some of my programs have extremely long names. Exacerbating this further, the programs are stored deep in the abyss of a network drive. This causes problems when trying to open from Windows Explorer. I believe the problem lies with SAS, but have tagged the question with Windows in case not. I'm hoping there is some way to address this problem via a configuration file or an edit to the registry.
To open a program, I typically double click on the .sas file in Windows Explorer. This opens the Enhanced Editor after a brief waiting period in which a SAS message box states:
The SAS System is processing requests. Please wait...
When a program's full name, including path and extension, exceeds 182 characters (i.e. has form: \\network-location\a\bunch\of\....\folders\program path exceeding 182 char.sas), the same "SAS System is processing requests" message appears, but then a Windows error is generated.
Not surprisingly, no solution is proffered by Windows.
When the program name is such that the full path is exactly 182 characters, nothing happens. I double click on the program and the only result is to select the file in Windows Explorer. If I monitor "Processes" within the Windows Task Manager, no new processes are started when such a program is double clicked.
When the program name is such that the full path is less than 182 characters, the program opens in the Enhanced Editor as expected.
According to MSDN, the max path is 260 characters. Clearly, 182 is well below that limit. SAS is the only application which has a problem with the path length. For example, I can copy the file name and extension, create a new text document with the same name (plus .txt) and open the file in Notepad, Notepad++, Word, Wordpad, Emacs, etc.
I have deduced two workarounds for working with names exceeding 182 characters.
If I open SAS via SAS.exe, I can load a program through the Open dialog with a path exceeding 182 characters just fine. This is not a good solution, however, as the Open dialog does not allow paths to be copy/pasted. The entire file path must be traversed. I can also drag such a program into the editor window within SAS to load it. This too is not a good solution, as a program will only load if there is a blank editor window. If the program is accidentally dragged on the the log window, it will execute automatically. Also, the program does not open in a convenient location. It opens in the middle of the Enhanced Editor and must be manually resized. That the programs can be loaded and executed at all leads me to believe that there is some way to fix this problem. It seems that somewhere in the process of loading the file, SAS violates some variable limit.
Of course, people would suggest that I use a different network location or shorter names. To the former, I am required to use a specific network location. To the latter, these programs are being developed in parallel with various reports. Many of the programs are similar and the corresponding references (table/figure numbers) in the reports change multiple times/aren't always communicated to me. Through experience, I've found the surest way to work with these uncertainties is to simply name the file by the label it's given in the report. Otherwise, I need to adopt unclear abbreviations, bad organizational practices, or introduce intermediate steps (like creating codes or a document which indexes the programs).
Edit: Per Joe's comment, it seems that the Open dialog allows copy and paste for specific file names. A file path can be copied in Windows Explorer via Shift + Right Mouse Click > Copy as Path and pasted into the "File Path" box in the Open dialog.
To avoid traversing the tree, the Current Folder may be updated before accessing the Open dialog. This is located at the bottom right of the Enhanced Editor.
The Open dialog starts at whatever the Current Folder location is set to.
I suspect your issue is that your 260 limit is in fact applicable.
When you double-click a program file, it doesn't just copy the path to SAS. Instead, what happens is SASOACT.exe is called, with a command of something similar to this:
"C:\Program Files\SAS94\SASFoundation\9.4\core\sasexe\sasoact.exe" action=Open datatype=Access filename="%1" progid=SAS.Application.940
That's well over 100 characters already by itself; presumably, behind the scenes, you end up with something like
"C:\Program Files\SAS94\SASFoundation\9.4\core\sasexe\sasoact.exe -open ""%1"""
Which adds around 70 or 80 characters to what you're passing it. Thus the 260 character limit.
You should use one of the workarounds - I personally prefer to just file->open, myself, but really whatever works best for you is fine. You could also consider using another editor for the simple double-click actions, though any editor you chose would still have some issues.
You could also consider asking IT to install SAS itself in a location that had a shorter path name, though realistically that might save 10 characters or so.
As for pasting; you can paste a path name just as easily as a file name into the file->open dialog. I have no idea why you don't seem to think you can, but I just did so now with no more difficulty than any other folder dialog...
Another workaround to consider, by the way, is mapping a drive letter to the network path. I.e., if your network path is
//myserver/projects/financial/projectnumber/.../
You map some letter (let's say R: arbitrarily) to that root path, //myserver/projects/financial/projectnumber, which is not changing anything other than how you refer to it locally. Then you can use:
R:\...\filename.sas
And you don't have to navigate paths, etc. You'd have to repeat that mapping process on any machine that you wanted to do this on, but if this mostly about your own workflow, that shouldn't be an issue. Just don't refer to R: inside the program itself and nobody else will ever know that you've changed anything.
When a user copies text to the clipboard, is it possible in Windows to programmatically identify the source file (and/or URL) and text position?
I have looked at a bunch of clipboard management applications (Ditto, clipboardFusion, ArsClip, and ClipDiary) and none appears to record the source of a clip.
It is my belief that this functionality in not possible, but I would like another opinion or two before I abandon my attempts.
I currently think the only way to achieve the desired behavior is to create an add-on / extension for every application that will be copied from. The extension would override the applications normal copy to clipboard behavior with a new format that adds the additional information. The key applications for me would be adobe acrobat (or another pdf reader) and a browser.
Windows does not require any source information to be given when setting clipboard data. Additionally, the only information needed to enable calling that function is a window handle. As such, the best windows could give you in a general case is the window handle that set the clipboard data via GetClipboardOwner.
Some applications set some of the formats on the clipboard to the source location of other data on the clipboard, but again in a general sense, there need not even be any source data; an application can just place random arbitrary data on the clipboard.
For your specific use case, you may be able to write a grease-monkey script to add your meta-data, and as firefox/chrome can display PDFs you might even be able to use the same script for PDFs.
I need to track copy-paste actions in Windows and Linux (I'm assuming gnome/unity) towards my app monitoring the clipboard content and the originating file's location (path)
How can I accomplish this?
Clipboard transfers contain data, not metadata. They may not be a "file" at all. If you want a standard GUI metaphor for moving files around, maybe you could consider Drag & Drop.
I'm implementing a custom URL handler in .NET. To test this, I have created a few different .url files and put them on my Desktop. This generally works fine, but behaves oddly if I change the file's contents, specifically the URL= line. Doing so has no effect — the old URL continues to be opened. Renaming the file, however, works. The file looks like this:
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,0
[InternetShortcut]
URL=myCustomScheme://some/url/pointing/somewhere
IDList=
All shortcuts I create through New → Shortcut receive the same UUID, so changing that probably won't help.
Is there some internal .url file / URL mapping cache in Windows?
I have a reason to believe that URL files are interpreted by some Internet Explorer component at the time of creation (not biblical). They are only interpreted initially, the first time the file is created. Any modifications to the URL file later on will not be committed. This is because the shortcut is not stored in the file. This is why the file can be modified later on so that it becomes empty, as a 0 byte file and the URL file will appear to be working anyway. The shortcut data is stored in the "Web Document" field as a file property in the NTFS file system. The file merely serves the purpose of pointing to it. You might be able to modify these property fields programmatically, which would supposedly "edit the file". It's a painful exercise just to edit what appears to be a simple text file.
Additionally, once a file name has been used for a URL file, it cannot be reused for new files, no matter what disk or path you save it to. So you have to keep assigning unique file names, never used previously, for each new URL file you create. This has to do with how Internet Explorer caches web content. It remembers what file names have been used already and maps those names to previously defined URL addresses. To reuse a name (or when you run out of ideas for new and unique file names) you have to clear Temporary Internet Files.
Windows 7: %localappdata%\Microsoft\Windows\Temporary Internet Files
Windows 8: %localappdata%\Microsoft\Windows\INetCache
To directly answer your question: yes, it does.
Windows 7 Caches your Filenames and sometimes, as you said, the filenames in specific locations.
Start regedit and search for the following
HKEY_USERS\S-1-5-21-x-x-x-x\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
where S-1-5-21-x-x-x-x is your currently logged in User.
There you can see that most (or all?) files have been cached which you have ever accessed.
Maybe you can also deactivate the MUICaching programatically. Maybe this site helps you: Disable Caching
I had a similar issue, and it turns out the culprit was Firefox.
If by chance your web browser is Firefox, your cache directories may be corrupted.
You can either create a new Profile, or take your chances cleaning things out of C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\
I've found my desktop .url shortcut contents cached in %LocalAppData%\Microsoft\Windows\Caches.
There are a few (several?) files with filenames like {<SOME_GUID>}.<x>.ver0x<XXXXXXXXXXXXXXXX>.db. Two of them had the .url files cached.
Unfortunately, I've found no information on what they are or how to refresh them. Everybody just deletes them as part of some cache clean-up operation.