KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Email   Bookmark

Understanding Unix/Linux Timestamp's

Views: 13282
Votes: 4
Posted: 29 Apr, 2010

Have you ever wondered what the 'ctime ', 'mtime ', 'atime ' and the occasional 'btime ' phrases are all about? What about an inode ? Well, the concept is really quite simple, once you understand what each means and what each is for on a Linux/Unix filesystem.

Linux/Unix filesystem's (such as Mac OS X , AIX, HP-UX, Solaris, Linux (all flavors), BSD and many others) all keep track of three standard system times.  Those times are the "change time" (ctime), "access time" (atime) and "modify time" (mtime).  There's an additional time that HFS+ filesystem's (MacOS) also make available and keep track of that's known as the "backup time" or "btime".

First, lets take a step back. The first thing to understand is that for each object on a Unix/Linux filesystem the filesystem stores administrative information in a defined structure known as an inode (also known as "metadata").  Each file on the filesystem is an object and therefore has this inode associated with it as a result. The administrative information about each file contained in the inode consists of:

  • The location of the item on the disk, if any
  • The item's type (file, folder, symbolic link (shortcut), etc)
  • The item's size in bytes, if applicable
  • The time the file's inode was last updated (the ctime)
  • The time the file's contents were last modified (the mtime)
  • The time the file was last accessed (the atime)
  • A reference count (number of names the file has)
  • The file's owner (UID )
  • The file's group (GID )
  • The file's mode bits (also called file permissions or permission bits)

Other information can be stored in an inode depending on the type of filesystem. One example is HFS+ filesystems.  HFS+ filesystems contain an additional time reference called the backup time (btime) which is updated each time the file is actually backed up.  The HFS+ filesystem is the successor to the HFS filesystem, both developed by Apple for their Macintosh computers.  All Mac OS 8.1 and higher filesystems run the HFS+ filesystem by default.

In the three standard times (ctime, mtime and atime), they are setup as follows:

Change Time (ctime): The timestamp of a file that is updated when the file contents have changed, ownership or permissions have changed, or the file's inode/metadata have been changed.

Moving a file through copy-and-paste will update the ctime because by copying the file it changes the atime of the file (part of the inode/metadata information) and creates a completely separate, completely new inode for the new file, leaving the original file and inode in-tact.

Moving the file through a cut-and-paste scenario will also change the ctime because the file is not being copied, it is being moved, which changes the location reference in the inode/metadata of the file as well as the atime for having accessed the file for the move operation.

Basically, if a file is changed in any way, whether it be the file's inode/metadata, contents, permissions or ownership, the ctime will automatically be updated by the filesystem.

Modify Time (mtime): The timestamp of the file that is updated when the file's contents change.  This time does not update when the file's inode/metadata changes, permission or ownership changes, or when moving (through copy-and-paste or cut-and-paste) the file.  The reason that the mtime does not change when using copy-and-paste or cut-and-paste operations is because the contents of the actual file have not changed in any way.

Access Time (atime): The timestamp of the file that indicates the last time the file was opened for reading by any Linux/Unix script, process, application or the like.  Opening a text document to read the document through any number of command line tools or graphical applications will change the atime of a file. Opening the file for backup changes the atime because the file was opened by an application for reading to backup the file.

When performing copy-and-paste operations, though a new file is created, the original file's atime will be updated because the original file was opened for reading to copy its contents.The atime is also updated in cut-and-paste operations because the file was accessed in order to update/change inode information.

The additional btime that's only found in HFS+ filesystems provides an additional tool to backup applications such as BRU .  This btime, when used, can greatly aid in the ability to know which files needs to be backed up and which ones have already been backed up.  The btime is setup as follows:

Backup Time (btime): The timestamp that only exists on HFS+ filesystems is the timestamp that indicates the last time the file was backed up.  This timestamp is only updated when the backup application (such as BRU) performs a backup of that file and it is up to the backup application to not only ask for the btime, but to update the btime as well.  The filesystem has no knowledge of what a file is being opened for and thus doesn't know that the btime needs to be updated.

When performing a backup of a file, the file is opened for reading, thus the atime changes.  The ctime is also changes because the file's inode/metadata (the atime reference) was changed.

We've created a reference chart to help visualize when each timestamp is changed.

Operation ctime atime mtime btime†
Copy X X    
Move X X    
Open/Read X X    
Update/Change X X X  
Backup* X X   X

* Only backup applications that call and change the btime, such as BRU, will actually change the btime of the file.  Further, after a backup by BRU the atime and ctime are reset back to their original values before BRU actually backed up the file, leaving the btime as the only timestamp that is changed. When using BRU from the command line the "-a" argument must be passed in order to achieve this result. † The btime is only available on HFS+ filesystems.


Others in this Category
document How do I properly rotate my tapes for incremental or differential backups?
document 2:1 Compression is Not Real World and Most Never See 2:1 Compression
document Image based backups versus file-by-file backups. Competitive or Complimentary Technologies?
document What are the proper settings for my tape drive or library and how does the BRU I/O buffer work?
document How to get OS X to mount drives on boot rather than login and leave them mounted when you logout
» More Articles

Powered by KnowledgebasePublisher
Page Load Time: 0.038161 seconds / 38.161 milliseconds.
Page File Size: 32289 bytes.