And what do you do when it’s not?
Drag and drop only copies very limited metadata, although it may be enough in some cases.
A Side Note on Scope
This analysis is limited to the most commonly-sought types of metadata.
Also, this analysis assumes that the files are being dragged and dropped from one NTFS drive to another. This is to protect your sanity and mine by keeping this analysis reasonably linear.
If the original files are stored on an NTFS file system but copied onto a FAT32 file system (which is used for most thumb drives), much metadata will necessarily be lost. See, e.g., Microsoft, “File System Functionality,” available at http://msdn.microsoft.com/en-us/library/windows/desktop/ee681827(v=vs.85).aspx (undated, retrieved March 20, 2014).
Possibly The Most Important Point In This Post
Any metadata stored in the bitstream comprising the file itself will reliably be copied along with the rest of the file. Here is an example:
This data, embedded by a digital camera in an image file, is an example of application or document metadata. It will always be copied along with the file:
Drag and drop will copy the “Modified” date as recorded by the file system. It will also copy the file’s “Hidden” and “Read-only” attributes. And, if the original file was downloaded from the internet, the copy will include that information unless the custodian has removed it. See Microsoft, “How to: Unblock a downloaded file to avoid security Warnings,” available at http://blogs.msdn.com/b/delay/p/unblockingdownloadedfile.aspx (undated, accessed on March 25, 2014).
If you copy a file that was encrypted using NTFS’ Encrypting File System onto an NTFS drive, it will remain encrypted. (However, if you copy it to a non-NTFS drive, the copy will be unencrypted.) Microsoft, “Encrypting File System overview,” available at https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/encrypt_overview.mspx?mfr=true (undated, retrieved on March 27, 2014).
The copy will not preserve the “Created” date or the “Accessed” date of the original file as recorded by the file system. Instead, because the copy is a new file, the “Created” date and the “Accessed” date will be the date on which the file was copied.
Also, because the copy is a new file on a new file system, the old security access permissions will be lost. Microsoft, “Controlling Access to Files and Folders,” available at http://technet.microsoft.com/en-us/library/cc938434.aspx (undated, retrieved on March 27, 2014).
Dragging and dropping individual files will not preserve the original location of the file in the source directory structure. One workaround is to copy a file or directory and to separately record the original path to that file or directory. So, for example, the collector could copy the entire “Documents” directory for a particular custodian and separately record the original path to that Documents directory.
Drag and drop is good enough only if you are certain that the only metadata that you may be required to produce will be the application metadata, the Modified dates, the “Hidden” and “Read-only” attributes, and whether the files were downloaded from the internet and not unblocked.
Microsoft’s free Robocopy utility can generally copy all file system metadata that might be required in the vast majority of cases, and can be operated by any reasonably competent Windows OS technician. See Microsoft, “Get to Know Robocopy for More Powerful File Management,” available at http://technet.microsoft.com/en-us/magazine/ee851678.aspx (undated, retrieved March 26, 2014).
DISCLAIMERS: All disclaimers apply, including but not limited to the following: This isn’t legal advice and I’m not your attorney, although I’d be happy to talk about it. The behavior of Windows may be randomly affected by many things including but not limited to operations involving computation. Some of the assertions above have been focused or otherwise bent through the lens of my own perceptions and/or expectations. I’d advise you to act accordingly but, as I said, I’m not your attorney.