Age Coloring

When you choose Age Coloring in the contextual menu, the icons are colored according to how old the file is. The color key here shows how.

The color is taken from the rainbow: Yellow files are "hot" and recently changed, Blue files are "cold" and pretty stable, and different colors of the rainbow in between represent whatever age in between.

For directories, the times depicted are actually the most recent times found in the directory and all of its subdirectories - not just the directory's time itself. This way, you can see if ANYTHING changed inside, no matter how deep.

During tallying of a large directory, there is a tendency for the directory colors to get more yellow as time goes on, because as the tallying proceeds deeper, there are more opportunities for more recent files to be discovered.

The most obvious color is the inside color for the icon, which shows you the modify (write) time.

The outside of the icon has its own color. This is the access (read) time. Often, this facility is disabled on certain volumes for performance and/or security reasons. If so, the outside color might be dark blue (reflecting a time long ago when the access times were last set), or it might match the Modify time. Even if the access time is available, Interrogator and other programs such as ls and find regularly scan through directories, setting the access time. When Interrogator decides that the access time is not useful, it simply colors the outside gray.

The file name itself has yet a third color - the Header time, sometimes called the Change time (sometimes confused with the Create time), sometimes called the Attribute Modify time. The Header time is updated when attributes about the file are changed. This time is useful for forensic analysis - it is harder to falsify, because the utime(2) system call can set the access and modify times, but not the header time. (The shell command to falsify the dates on a file is touch; commands are also available in perl and other scripting languages. All of these, however, go through the utime(2) system call bottleneck.) Indeed, for the animation above, you can see that the header time of jtear is always recent; we had to artificially set the file times for the sake of the demonstration.)

Time Flies

File timestamps are supposed to be set on files in the moment, but there's a variety of problems that can happen. If you wander around your machine with Interrogator in Age Coloring mode, you will soon find them, including files dated in the future.

Timezones are the most obvious reason for timestamps to be in the future. Someone in Rome makes a file at 10pm, at the same time it's 9pm in London, 1pm in California and 3:30am the next day in Bangkok, although the file may be available on a server to all at that moment. The timezone is usually not attached to the timestamp on a file; you simply get a date and time. To complicate this, much of the world shifts their time by an hour over the summer months for daylight savings time; the exact dates vary from one country to another. In the mid-1970's, the US shifted by two hours for two years by presidential decree. Different states, provinces and regions declare their own time zone systems.

For refuge, people generally trust UTC time, similar to Greenwich Mean Time, a universal time system that's roughly the same as local time in Greenwich, a suburb of London. Frequently, computer systems have their inner clock set to UTC and use conversion algorithms to get a local time. This eliminates the need to actually change the clock when Daylight Savings Time comes around, and eliminates the confusion when two helpful agents try to do this adjustment on your behalf, such as when multibooting Linux and Windows systems.

Many of the timestamp problems you see come from unimplemented features. Virtual files created on the fly by the Kernel, such as the /proc system, or different things in the /dev directory, can have dates that are simply not filled in, or the dates returned can always be the current date.

File timestamps can be set artificially. At the Unix command line, use the touch command with the -t option. On Mac OS, use ResEdit or Resourcerer. In BSD software, use the utimes() system call. Typically these methods can change the Modify and Access times, but not the Header time.

Sometimes computer clocks go dead. If you see dates in 1904, most likely this comes from a Macintosh whose clock battery died. Mac OS uses a 32 bit integer counting the number of seconds since 1904, so many a recently revived machine thinks it's January 1, 1904.

Some fileserver systems try to mask the time differences between servers. Servers in London and Paris will decide that their clocks are off each other by an hour, so that file dates are distorted to accomocate as they are seen across the English Channel. These new dates get ratified as files are copied between machines. Then, if one machine's date falls back to 1904, file dates are changed by a century as they move back and forth. Since 32 bit integers only accomodate about 136 years before they overflow without warning, the result might be a date in the middle of the 20th century.

Documentation > Directory Window > Age Coloring
T a c t i l e   I n t e r r o g a t o r   W e b s i t e