Fri, 23 Sep 2011 22:00:00 GMT
Unix-Files are saved with three time-values in the meta-information: The atime, the ctime and the mtime. The ctime is set when a file is changed. Similarly, mtime is set when the file is modified. The difference to the ctime is that ctime is also set when the file is renamed or the permissions are changed, while mtime is set when the content of the file is changed. These values are completely intuitive.
Now, there is the atime. I always thought it saves the timestamp of the last time the file is accessed. That is why I usually mount my file systems with the noatime option: I do not want every read access to result in a write access of header information of a file.
As I said, I thought, atime means that the file is accessed. That is, we would always have atime >= mtime >= ctime. This is wrong - and probably my conception of "access" is wrong.
Accessing means reading or writing - at least in my humble opinion. But atime is only updated when the file is read. It is more like a read time than like an access time. So actually, atime can be smaller than mtime: If the file was modified but not read afterwards. In the first moment, that did not make sense to me, but seeing that some mailclients like mutt actually use atime, it became clearer: If you have mails that have been sent, the file modification time is the time when the mail has been received. The read time is the time when the mail has been read the first time. Therefore, using these values gives you a mechanism of keeping track of read and unread mails.
I do not think that this is still a good way of programming, because disks are large enough to save this meta information in the data part of a file, and atime is not always accessible or correct, but of course, if you want to use meta information for this, it makes sense, and in the past it may have been a reasonable setup.
An interesting alternative to the noatime mount option is the relatime mount option: It updates atime only if atime <= mtime, that is, only if the file has been modified since the last read access. That way, mutt and other software using these times to manage their read flags still works.
This is a hack. A hack which is both stupid and ingenious. It is one of these hacks that you usually see when people talk about Windows internals.
Now, there is the atime. I always thought it saves the timestamp of the last time the file is accessed. That is why I usually mount my file systems with the noatime option: I do not want every read access to result in a write access of header information of a file.
As I said, I thought, atime means that the file is accessed. That is, we would always have atime >= mtime >= ctime. This is wrong - and probably my conception of "access" is wrong.
Accessing means reading or writing - at least in my humble opinion. But atime is only updated when the file is read. It is more like a read time than like an access time. So actually, atime can be smaller than mtime: If the file was modified but not read afterwards. In the first moment, that did not make sense to me, but seeing that some mailclients like mutt actually use atime, it became clearer: If you have mails that have been sent, the file modification time is the time when the mail has been received. The read time is the time when the mail has been read the first time. Therefore, using these values gives you a mechanism of keeping track of read and unread mails.
I do not think that this is still a good way of programming, because disks are large enough to save this meta information in the data part of a file, and atime is not always accessible or correct, but of course, if you want to use meta information for this, it makes sense, and in the past it may have been a reasonable setup.
An interesting alternative to the noatime mount option is the relatime mount option: It updates atime only if atime <= mtime, that is, only if the file has been modified since the last read access. That way, mutt and other software using these times to manage their read flags still works.
This is a hack. A hack which is both stupid and ingenious. It is one of these hacks that you usually see when people talk about Windows internals.
Show comments (Requires JavaScript, loads external content and cookies from Disqus.com)