• Facebook
  • Twitter
  • RSS
Bits in the Balance
  • Home
  • Services
  • Practice Areas
  • About
  • Cases
  • Contact
  • Blog
Select Page

Metadata – When is Drag and Drop Good Enough?

by Joshua Neil Rubin | Mar 27, 2014 | Uncategorized | 0 comments

And what do you do when it’s not?Copy cursor

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:

application metadata

photo metadata 2

The Rub

In stark contrast, the dates and “Attributes” in the illustration below, which the file system stores in its database, are examples of system metadata, some of which gets copied nicely, and some of which doesn’t:

System Props

Specifically,

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.

In Short,

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.

Workaround/Safety Net:

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.

Trackbacks/Pingbacks

  1. steve hollatz | Metadata – When is Drag and Drop Good Enough . . . | Bits in the Balance - steve hollatz - […] Metadata – When is Drag and Drop Good Enough . . . | Bits in the Balance. […]

Submit a Comment Cancel reply

Your email address will not be published. Required fields are marked *

Search All Posts

Recent Posts

  • Litigation-Ready Text Messaging
  • Hillary’s Emails, Weiner’s Laptop
  • Cooperation in Ediscovery: Counsel’s Database
  • Predictive Coding: Networks and Trees
  • Ediscovery: Information is Free

TAAC

algorithm black box collaboration collection competence computational linguistics confidentiality cooperation corpus linguistics Craig Ball de-duplication deduplication document review ediscovery ediscovery industry ediscovery protocol ediscovery software email esi FRCP FRE Gordon V. Cormack hashing Jason R. Baron key phrases key players key words lexical litigation Maura R. Grossman metadata Paul Grimm predictive coding privilege project management proportionality search Sedona seed concept seed sets statistics teamwork technology-assisted review workflow work product
  • Facebook
  • Twitter
  • RSS

Designed by Elegant Themes | Powered by WordPress