Solaris Troubleshooting : Display 3 timestamps ( at, ct, mt) for a file – in solaris

First, an explanation of the time stamps:
mtime - time the contents of file was last modified (written to).
atime - time the file was last used/accessed (read or executed)
ctime - time the inode of the file was last changed (like changing permissions).
ctime also gets updated every time mtime is modified, but not when the atime is changed.
ctime, is NOT the files creation date.   Creation date is NOT recorded  anywhere in the Unix file system.


To get all 3 time stamps for a file, we can use the ability of truss command to trace the lstat system call which ls uses to get information about a file it is listing:
Example:
1. Create a file
      $ touch test.file
2. Print out the time stamp information by trussing the ls -l command:
"truss -v lstat -t lstat" sets up the truss of the "ls -l test.file" command.
$ truss -v lstat -t lstat ls -l test.file
lstat64("test.file", 0xEFFFF158)                               = 0
d=0x03040002 i=164508 m=0100644 l=1   u=84474 g=10       sz=0
at = Jun   6 11:12:20 EDT 1999   [ 928681940 ]
mt = Jun   6 11:12:20 EDT 1999   [ 928681940 ]
First, an explanation of the time stamps:
mtime - time the contents of file was last modified (written to).
atime - time the file was last used/accessed (read or executed)
ctime - time the inode of the file was last changed (like changing permissions).
ctime also gets updated every time mtime is modified, but not when the
atime is changed.
ctime, is NOT the files creation date.   Creation date is NOT recorded
anywhere in the Unix file system.
To get all 3 time stamps for a file, we can use the ability of truss command to trace
the lstat system call which ls uses to get information about a file it is listing:
Example:
1. Create a file
$ touch test.file
2. Print out the time stamp information by trussing the ls -l command:
"truss -v lstat -t lstat" sets up the truss of the "ls -l test.file" command.
$ truss -v lstat -t lstat ls -l test.file
lstat64("test.file", 0xEFFFF158)                               = 0
d=0x03040002 i=164508 m=0100644 l=1   u=84474 g=10       sz=0
at = Jun   6 11:12:20 EDT 2010   [ 928681940 ]
mt = Jun   6 11:12:20 EDT 2010   [ 928681940 ]
ct = Jun   6 11:12:20 EDT 2010   [ 928681940 ]
bsz=8192   blks=0         fs=nfs
-rw-r--r--     1 peteski   staff                   0 Jun   6 11:12 test.file
The above output shows all 3 timestamps in an "human readable" format, and in a
"seconds since epoch" number ( in square brackets ).
The output also contains other useful information (see stat(2) man page for details).
Depending on which kernel is in use, you might see lstat64 instead of lstat.
NOTE:   due to the fact that the timestamp is recorded in the inode as "number of
seconds since epoch", the highest granularity of the timestamp is 1 second.
This is a ufs "feature" and is not related to the 32 or 64 bit kernel.
If some application creates several files within 1 second, trying to sort them using
the timestamp will not produce the desired result (since the timestamp will be the same
on all of them). If multiple files have an identical timestamp, they will be sorted
by their filename (as a secondary sort criteria) by commands such as "ls -t"..
INCLUDED FOR REFERENCE (excerpt from stat(2) manpage):
st_atime
Time when file data was last accessed. Changed by   the
following     functions:     creat(),     mknod(),     pipe(),
utime(2), and read(2).
st_mtime
Time when data was last modified. Changed by the   fol-
lowing   functions:   creat(), mknod(), pipe(), utime(),
and write(2).
st_ctime
Time when file status was last changed. Changed by the
following     functions:     chmod(),     chown(),   creat(),
link(2),   mknod(),   pipe(),   unlink(2),   utime(),   and
write().

[ 928681940 ] bsz=8192 blks=0 fs=nfs -rw-r--r-- 1 peteski staff 0 Jun 6 11:12 test.file
The above output shows all 3 timestamps in an “human readable” format, and in a seconds since epoch” number ( in square brackets ).The output also contains other useful information (see stat(2) man page for details). Depending on which kernel is in use, you might see lstat64 instead of lstat.

NOTE: due to the fact that the timestamp is recorded in the inode as “number of seconds since epoch”, the highest granularity of the timestamp is 1 second. This is a ufs “feature” and is not related to the 32 or 64 bit kernel. If some application creates several files within 1 second, trying to sort them using the timestamp will not produce the desired result (since the timestamp will be the same on all of them). If multiple files have an identical timestamp, they will be sorted by their filename (as a secondary sort criteria) by commands such as “ls -t”..

st_atime Time when file data was last accessed. Changed by the following functions:

creat(), mknod(), pipe(), utime(2), and read(2).

st_mtime Time when data was last modified. Changed by the following functions:

creat(), mknod(), pipe(), utime(), and write(2).

st_ctime Time when file status was last changed. Changed by the following functions:

chmod(), chown(), creat(), link(2), mknod(), pipe(), unlink(2), utime(), and write().


Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us