After we copy a file, we can wait for long before pasting it to the destination.

I have googled but can't figure out where windows store the information of the source file.

I don't think it's the clipboard who is responsible for data exchange


It's the clipboard. There's quite a number of different pieces of data (clipboard objects) that can be stored in a single clipboard entry, different pieces of data describing the same entry.

The most common approach is to store a pointer to the file, usually the file's path. This is usually in the CF_HDROP format. The program performing the paste operation needs to support this format, and can go and read the file that it's pointing to. This is what Windows Explorer does.

It's also possible to store an entire file's data in the clipboard, which is later pasted out of it. This is usually used for transient and small files, and is rather inefficient. Outlook is one such application, when you copy (or drag-drop) an email. This is not supported by nearly as many applications as the pointer approach is; for example, it's not possible to paste or drop these into most web browsers.

  • ...& this is the reason cut/paste can be so dangerous in Windows. Change the buffer, lose the file. – Tetsujin Sep 5 '18 at 6:19
  • 1
    @Tetsujin If you're cutting from Explorer, it simply stores a reference. The source file is not removed until after the paste operation is complete. It's modeled as a copy => paste => delete (or a move, if on the same volume). There's nothing dangerous about it. – Bob Sep 5 '18 at 6:20
  • Google 'cut paste lost files'. – Tetsujin Sep 5 '18 at 6:28
  • 1
    @Tetsujin As usual, nothing of substance. Data loss from interrupting the process (by unplugging devices, power loss, etc.) has nothing to do with the transfer method but rather how write caches in both the OS and on the disk (hardware/firmware) work. Given that "cut" literally does nothing more than add a file path to the clipboard and mark the file, there is no way for "cut" to be dangerous. The file transfer operation itself (which is outside the realm of cutting/clipboard and can be achieved by, e.g., right click => move to) is a different matter. – Bob Sep 5 '18 at 6:34
  • OK. I shall continue to never trust it. macOS doesn't even have a cut for files in Finder, you can only invoke 'cut' at paste time. – Tetsujin Sep 5 '18 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.