7
  1. About mtime of a directory, from Stéphane Chazelas's reply https://unix.stackexchange.com/a/187231/674

    The modification time of a directory, like any other file (note how directories are called directories (a list of name/number mappings like a phone directory) and not folders) is updated whenever the content is modified.

    That is when a file is added (linked), removed (unlinked), or renamed in it.

    Does it mean that a directory's content about a child file is only the filename of the child file, and the number of hardlinks to the child file?

    If not, what other info of a child file is in the content of the parent directory?

    In other words, changing what of a child file will also change mtime of its parent directory?

  2. When does the atime of a directory change? I found that neither of ls -l, ls -ld and cd changes ctime of a dir. I thought the commands display the directory's content, and therefore reads the directory's content?

  3. When does the ctime of a directory change?

Thanks.

1 Answer 1

6

Think of a directory as a text file that looks something like:

123:foo.txt
234:bar.txt
123:other-name-for-foo.txt

That's all there is (at least in traditional Unix file systems).

foo.txt is not a child of that directory in that it's not an exclusive relationship. It's just that the file of inode number 123 is referenced in two entries of that directory: with names foo.txt and other-name-for-foo.txt.

Those two directory entries are also known as two hard links to the same file.

$ touch foo.txt bar.txt
$ mkdir other-dir
$ ln foo.txt other-name-for-foo.txt
$ ln foo.txt other-dir/whatever
$ ls -i . other-dir
.:
58892735 bar.txt  58958143 other-dir/
58879562 foo.txt  58879562 other-name-for-foo.txt

other-dir:
58879562 whatever

. and other-dir are two files of type directory, each containing a number of directory entries. ls lists the entries of a directory whose names don't start with . and with -i includes the inode number.

With -a (to include dotfiles), and -i (ls -ai), that's more or less dumping the content of that text file I was mentioning above.

You'll notice that the file of inode 58879562 above is linked once to other-dir and twice to .. That 58879562 file now has a link-count of 3, but neither . nor other-dir care about that. That information is stored in the inode of the file and is just for the system to keep track of how many times the file is linked to a directory. If that number falls to 0, the disk space occupied by that file can be reclaimed.

In addition to inode number and name, directories also contain the file type of the file (regular/fifo/directory/symlink/device..., though not for all file systems). That information can be retrieved otherwise (as it's stored in the inode) so is not necessary. It is done mainly for optimisation purposes and because it's possible. It is possible because it is not possible to change the type of a file (contrary to other metadata), so that information stored in the directory is not going to become out-of-sync with the reality.

You'll also notice that the system call to remove a file is not remove("/foo/bar") but unlink("/foo/bar"). That's because all it does is remove the bar entry from the /foo directory, it unlinks bar from /foo. That file may still be linked to other (or the same by a different name) directory. It's only going to be removed when its link count reaches zero (when it's no longer linked to any directory).

As to why doing an ls doesn't update the access time of a directory, that's probably because your filesystem is mounted with the noatime or relatime option.

Updating the access-time of a file (directory or other) every time it is read is costly, so many systems give up on that nowadays.

Note that the system, if not the user reads directories all the time.

For instance, when accessing /foo/bar, the system needs to read the content of / to find foo and then /foo to find bar (though most of the time that information is cached). However, in those cases, the atime is not updated (thankfully), only when user-space processes explicitely read the content of a directory like ls does.

As to when the ctime of a directory is updated, that's the same as for a regular file: when its content is modified (entries added or removed or renamed) or its metadata (except atime upon reading) is modified (like upon chmod/chown, ACL modifications...).

5
  • Thanks. "in those cases, the atime is not updated (thankfully), only when user-space processes explicitely read the content of a directory like ls does." Do you mean ls doesn't update atime of a dir, but a user space process which explicitely read the content of a dir does? What does "user-space processes explicitely read the content of a directory like ls does" look like?
    – Tim
    Commented May 6, 2015 at 22:47
  • 1
    ls is a user-space process (as opposed to kernel code reading directories to look files up from a path in a file system) that explicitly opens and read the content of directories, so it does cause the atime of directories to be updated (on those file systems where atime is not disabled). Commented May 7, 2015 at 8:37
  • On a different linux machine, I found that the mtime of a dir doesn't change when the mtime of a file in the dir updates. Why isn't the mtime of a dir updated as well?
    – Tim
    Commented May 13, 2015 at 2:51
  • @Tim, isn't it exactly what you asked in your other question? Commented May 13, 2015 at 8:27
  • Right. sorry, I forgot.
    – Tim
    Commented May 13, 2015 at 11:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .