site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Apr 22, 2009, at 5:01 AM, Rohan Kulkarni <rohan.ak1@gmail.com> wrote: Hello, I moved a file from one directory to another on the same partition. However, when a do a stat on the file before and after the "move" the inode change time(ctime) does not get updated. Why is this? Because you haven't changed the file contents. Since you didn't change the contents, the file change time (ctime) is not updated. You are looking at the wrong timestamp field. The mtime may or may not be updated; depending on the internal implementation details of a particular file system, the rename may be treated as a link plus an unlink, in which case the link count goes from N to N+1 and back to N non-atomically, even if the rename is idempotent; since it's not an atomic operation in that case, it counts as two metadata updates. Alternately, one of the pieces of metadata that could be maintained on a per file object basis could be a pointer to its container. If either of these were true, then there would be a metadata time stamp (mtime) update. If what you rename is a directory, then the .. file in the directory is rewritten in the renamed directory to point to the parent. Again, as an implementation detail, if directories are implemented using file content, then the crime will be updated. If they are not, then the mtime will be updated. Since file times updates in POSIX are only mandated for file objects, as a technicality, it may be that only the containing directories rather than the directory which us renamed get updated. In any case, a sufficiently privileged process can set the timestamp fields to whatever it wants (otherwise it would be impossible to implement image backup and restore programs), which would also make structural changes undetectable by naievely examining timestamps. To learn more about the timestamp fields and "shall be marked for update" vs. "shall be updated" events, you should read Go Solo: The Single UNIX Specification. This document is also called POSIX 1003.1-2003, and is available for viewing online at The Open Group web site. If you are attempting to detect rename events for security purposes, you should search for "kauthorama" on <http://developer.apple.com>, and expect that your solution will require you writing a KEXT. This email sent to site_archiver@lists.apple.com