Copying v Dragging a file to an OS X Disk Image

Had a need to do some quick testing on different operations on OS X 10.10.5 (Yosemite) and thought I’d share (plus ask for some assistance).

I created a new disk image, and then copied an existing file into it. I then created a new file, and dragged that into the disk image. Here is what I found!

Copy Existing File

I had a file which had some text in it, it was called “hello.txt”. I hadn’t changed it in a few days, but I did open it just before I ran the “stat” command to see what was inside. This is reflected in the “Access” timestamp. (For some reason stat doesn’t give the created date, but it was shortly before the change date).


To get additional information, I ran “mdls” as well: This shows way more information, and a lot of different timestamps!


Not a very interesting file; I created it, wrote some text and then opened it a couple of times. The kMDItemLastUsedDate shows the last time that I opened the file (in UTC), and the kMDItemUsedDates shows that I opened it on two separate days.

I did a brief amount of testing on the kMDItemUseCount, and that appeared to go up by 2 every time I opened the file. I have no idea why.

I also took a look at the extended attributes but not much super interesting there.


I copied the file into my test image (HFS+ formatted), and observed the following:

  • The “Created” and “Modified” timestamps remained unchanged; and
  • The “Date Last Opened” appeared to reflect the modified date for some reason.
  • The “Date Added” field remained unpopulated.


I ran stat over the new file in the mounted image, and saw that the Access and Change dates reflected the move time, but they aren’t displayed in Finder.


Interestingly, mdls gave significantly less information on the copied file than the original; which makes sense, it’s a new file. OSX does maintain some of the previous data though (Extended Attributes for example)


Also interesting, I searched specifically for the LastUsedDate and it spat out a value, but didn’t show that in the previous mdls command. I have no idea why.


DateAdded remained null though.


Ok! What can we say: From looking at the Finder view only, you won’t be able to tell when a file is copied into an image. The dates remain the same, and the Date Added field isn’t populated.

mdls isn’t super helpful either, but stat will give you the “Access” and “Changed” date. These can most probably be correlated with fsevents (which I need to learn more about).

The “LastUsedDate” (which I think is “Last Opened” if you go to the files info in Finder) is also unreliable as I haven’t opened the file in its current location. If the “Created Date” matches the “Last Opened Date” then the file may not have been accessed.

Drag Existing File

Next I created a new file, world.txt, and here’s the metadata for that one.
(Opened Textedit, mashed some text, hit save).


From here, I dragged the file from my Desktop into my mounted image and then extracted the metadata.

Again, my Access and Change dates reflect the move – bear in mind I haven’t accessed the file, so these will most likely change if I do.

Again, not too much metadata coming from mdls (at least not in comparison to what I get from the original file), but still keep the extended attributes.


I specifically searched for DateAdded here, and it’s still null.


Which is really confusing because Finder is showing me a “Date Added” and it reflects my drag operation!


Date Last Opened is currently reflecting the Created date of the file as I haven’t opened it yet.

I then opened the file, and the “Date Last Opened” in Finder didn’t update. I have no idea why. The “Access” timestamp in stat however did.

Ok! So what do we know now:

If I dragged a file from a to b, a new file is created, but this time the “Date Added” field is populated. This reflects when the file was dragged here. If anyone knows how I can get this timestamp from the terminal, please let me know, because I can’t seem to figure it out.

The “Date Last Opened” column in Finder appears to be unreliable, as it doesn’t reflect when I last opened the file, but running “Stat” gave me an accurate timestamp for the last time the file was opened (note: other things can change this timestamp, I’m just not sure what else yet). Either way, I wouldn’t rule out that a file has been accessed because Finder indicates that the last opened and created dates are the same – Hopefully you have other artefacts to help support the files being accessed.

If anyone would like to confirm what I’ve found, or add to it, please do. It would be quite helpful!


Funny thing happened, I copied the image to another Mac (running 10.13.6) and took a screenshot of what I saw.

Screen Shot 2018-08-29 at 6.37.33 pm

The ‘Date Added’ is present for all three items, which is not the same behaviour that was seen on the previous OS; at least from a presentation standpoint.

This does mean that my theory that the two operations were treated differently may be false, but at the very least I can show that the ‘Date Added’ shows when the file appeared on the volume.

3 thoughts on “Copying v Dragging a file to an OS X Disk Image

  1. Are you getting same results after a machine restart assuming that things aren’t quite synced between databases on disk and memory at the time? And mdls and finder may be using different API calls perhaps.


    • Didn’t restart but have mounted and unmounted with things remaining consistent.
      Strange behaviour because the timestamp for date added appears to be there (as evident in forensic tools, and current versions of OSX for the same data)


  2. […] Over on my ThinkDFIR page, I took a look at copying and dragging files from an OSX 10.10.5 host to a disk image to see what happened with the filesystem timestamps. Interestingly, the “Date Added” timestamp was updated, but not always displayed on that OS. When I moved the image to a later version of MacOS (10.13) I was able to verify the “Date Added” timestamps were updated when the files were created on the image. Copying v Dragging a file to an OS X Disk Image […]


Leave a Reply to Yogesh Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s