I just moved some files from my desktop to a laptop via a thumb drive. The copy that arrived on my laptop showed the most recently modified item as a folder containing some documents and a PDF. The documents/PDF show the correct modification dates (weeks ago), it’s only the folder containing those files that shows as being modified today (at the same time as I transferred the whole big batch of files). No other documents, images, PDFs, or folders were affected.
I don’t think it’ll help. If a folder is copied to another drive, the hierarchy of the folder that was copied will end at the drive name (as would the original’s).
Open the folder and move the screen pointer to the folder’s title and hold the mouse button down while holding down the Command key.
The folder’s place in the hierarchy’s pecking order is displayed, but that would do little to explain why that folder’s modification date changed.
I’m unclear as to what those commands on a Windows machine would do, other than display a pathway. Would they reveal when the folder was modified? Does a folder copied to a flash drive retain a link to the original?
The syntax would make sense to a Windows user, but it’s all Greek to me and to TSBG. The Mac terminal runs on Unix commands, but it doesn’t need the terminal to display a pathway. There are at least two other ways to do that.
Just now I created a folder on my desktop machine. I named it Ruins Pic Inside. I dropped a photo of a collapsing wooden building into it to give it content. The folder pathway: Hard Drive/Users/Kenm/Desktop/Ruins Pic Inside
I dragged the folder to a flash drive where it copied (dragging a folder or file to another drive doesn’t move it; it’s copied). The folder pathway on the flash drive: Flash Drive/Ruins Pic Inside
There’s no information as to where the folder Ruins Pic Inside came from, and the modification date of the folder did not change.
I deleted the desktop version of that folder, then copied the flash-drive version back to the iMac desktop. The folder’s pathway is identical to the original’s and the modification date did not change.
So it appears that the reason for the modification-date change made to TSBG’s folder remains a mystery.
The Mac filesystem has some normally hidden files that get modified when you do things like rearrange icons or change other finder settings for that folder: .DS_Store
Even though by default you can’t see those files, they’ll still change their parent folder’s modified date when they get changed.
If an ordinary file on a Mac is modified it won’t cause a change to the parent directory (containing folder).
The Mac filesystem is a curious beast. In many ways it looks like a Unix filesystem, and it presents that interface via the command line utilities that any Unix user would be used to. Underneath it still preserves some of the old style Mac HFS features, and these can complicate matters. But for the OP’s question that won’t matter.
Directories give files their names. Unix files don’t have names by themselves, they are referenced by name/file-reference pairs in directories. A file can have multiple such references, and they are all equal in standing. When the last one goes away the file vanishes. That name-reference pair is all that is in a directory. But directories always contain a reference to their parent directory. This, by convention has the name … Directories also contain a reference to themselves, by convention this has the name “.”
If you move a directory from one part of the file system to another, you will need to change the reference to it’s parent directory (the one called …) So the directory is modified.
If the directory is a copy of one from another device (and thus not simply moved within a filesystem) it will be copied. The order of events may dictate exactly what happens, but in order to create the correct reference back to the directory’s parent, logically the … entry must be modified, and thus the directory is modified.
The OP didn’t say if the creation date was as expected, and only the modification date that was changed.
Francis Vaughan did a great job of explaining why a folder’s modification time should change when it’s moved. On older versions of Unix one would, similarly, see the modification time change.
However, even old versions of Unix have a system call to overwrite the modification time; this is useful with a command like cp -p – copy while preserving timestamps. And the Linux mv and cp utilities do indeed deliberately preserve the old modification timestamp. Judging by Kenm’s response, so does Mac. This makes me think buckgully has the right answer.
From the Trivia Desk:
With Unix/Linux there are three timestamps associated with each file or folder: time of last access, time of last modification, time of last change. Unlike Windows, there is no time of creation. The change timestamp, which is set whenever the modification timestamp is set, may seem redundant, but the change time is changed in certain circumstances when the modification time is not changed (e.g. when permissions are changed).
Moreover, while there are system calls to set access and modification times to any programmer-specified value (i.e. to tell a lie! ), there is no system call to set the change time. (You can do it if you wish: just write to the raw disk device!)
In Unix you can see the change time with a command like ls -cltd .
So Mac’s have creation timestamps. Do they also have change timestamps?
Yes.
ls -lc for status change (so ctime),
ls -l for modification (so mtime) (-t to sort with mtime)
ls -lu for access time,
and confusingly, ls -lU for creation time. (When -U usually means unsorted.)
The file system is rather different under the hood, and there was once a remarkably clear and well thought out design paper from Apple discussing the issues of mapping Unix and Mac file system semantics. For some things you simply can’t do it. Like case sensitivity.