Time stamps on directories/subdirectories and files

[Manoj1]

Hi All,

I had seen some situation where time stamp on directory/sub-directories was older but files it contains has newer ?

How does time stamp work in HP-UX or other Unix ?

Thanks,
Manoj

[Matti_Kurkela · Accepted solution]

In a "standard" Unix system, each file and directory typically has three timestamps:

- mtime = time of last file modification. This is the timestamp you normally see in the "ls -l" listing, although you can see the other timestamps if you add the appropriate options to the ls command.

- ctime = time of last change of the inode metadata (= ownership, permissions, which disk blocks are allocated to this file, the count of hard links to a file, etc.)

- atime = time of last data access

The atime is usually the least useful of these three timestamps. If the filesystem is mounted with the "noatime" mount option, the atimes are not tracked, which reduces the number of disk writes required.

Someone may misguidedly talk about "creation time": this is a persistent misunderstanding. Please don't spread it.
Although *some* Unix filesystems may have one, it's not a standard Unix timestamp and HP-UX filesystems don't record creation times.

The name of the file is *not* part of the inode metadata: it's part of the directory the file is located in. This may be surprising, but it's related to the Unix feature of hard links.

In a Unix filesystem, a single file can effectively be present in multiple directories simultaneously, if multiple directories have a hard link to the inode of the file. A normal file with just one hard link is just a special case of that. The unique identifier of a file is *not* its name, but its inode number.

In Unix, directories are fundamentally just special files that map filenames to inode numbers. When you understand this, the behavior of the timestamps will start to make sense to you.


When you write to an existing file, you change the data within the file, and the block allocation information in the inode metadata, so both mtime and ctime will change. No changes are made to the directory, so the timestamps of the directory won't change.

When you create a new file, a new filename->inode mapping is added to a directory; so the directory's mtime and ctime are changed.

When you rename a file within a particular directory, you modify the directory, so the mtime and ctime of the directory are changed. The rename operation within a single filesystem is done by creating a new hard link using the new name, and deleting the old link, so the file's link count gets updated to 2 and then back to 1, and so the file's ctime gets updated too.

When you delete a file, you effectively remove its hard link from the directory it's in. This is a directory modification, so the directory's mtime and ctime are changed.

The link count in the file's inode is decremented by one; if *and only if* the link count reaches 0, all its hard links are gone, the file can be deleted and the disk blocks assigned to the file can be added to the list of free blocks. But if some process is currently accessing the file (has the file opened), this part of the removal operation will be delayed until the process closes the file.

MK

[Ismail Azad]

Hi,

In addition to matti's eloquent explanation, i would also like to add that the find command can be used to search for files and directories with the atime, mtime and ctime options. However, you will see that the atime option is used when an administrator is trying to find or cleanup certain "large and old files". One more interesting point I would like to add is that doing a touch on an already created file just updates the timestamp.

Regards
Ismail Azad

[James R. Ferguson]

Hi Manoj:

> I had seen some situation where time stamp on directory/sub-directories was older but files it contains has newer ?

That's not uncommon at all. The 'mtime' (modification timestamp) of a directory changes when files are added to it or removed from it. Changing a *file* within a directory will change the file's 'mtime' but not the directory's.

Regards!

...JRF...