7

When I run the stat command, what is the output actually showing? I know you can specify format, but I'm troubleshooting rsync from OS X to NetApp SMB, and trying to work out what is and is not copying..

# stat /Volumes/Media/MediaBank/WEB_D/41/zoomify/41999V21.jpg
234881039 281475121196473 -rwxr--r-- 1 mbank wheel 0 378716 "Aug  9 19:17:50 2010" "Jan  3 12:56:26 2010" "Apr 26 09:34:13 2010" "Dec 27 23:35:32 2009" 16384 768 0 /Volumes/Media/MediaBank/WEB_D/41/zoomify/41999V21.jpg

And this is the copy rsync'ed to the SAN..

# stat /Volumes/SAN_Media/MediaBank1/WEB_D/41/zoomify/41999V21.jpg
771751969 10654547399 -rwx------ 1 root wheel 0 378716 "Aug  9 09:39:45 2010" "Jan  3 12:56:26 2010" "Jul 23 17:52:30 2010" "Jan  3 12:56:26 2010" 33028 744 0 /Volumes/SAN_Media/MediaBank1/WEB_D/41/zoomify/41999V21.jpg

My guess on the output format is this..

unknown1 unknown2 permissions unknown3 uid gid linkcount bytes time1 time2 time3 time4 unknown4 unknown5 unknown6 fullpath ..

As for the times, I guess three of them have to be atime, mtime and ctime, but why is there a 4th one and which one is which?

Chealion
  • 26,327
user33688
  • 81

4 Answers4

12

I'm not a OS X user, but I'm familiar with FreeBSD. The stat output with it looks the same than yours, but if you want to clarify things to be human-readable, use stat -x your_path.

Oh, what are those fields? Perhaps this snippet from OS X documentation helps:

struct stat { /* when _DARWIN_FEATURE_64_BIT_INODE is NOT defined */
     dev_t    st_dev;    /* device inode resides on */
     ino_t    st_ino;    /* inode's number */
     mode_t   st_mode;   /* inode protection mode */
     nlink_t  st_nlink;  /* number or hard links to the file */
     uid_t    st_uid;    /* user-id of owner */
     gid_t    st_gid;    /* group-id of owner */
     dev_t    st_rdev;   /* device type, for special file inode */
     struct timespec st_atimespec;  /* time of last access */
     struct timespec st_mtimespec;  /* time of last data modification */
     struct timespec st_ctimespec;  /* time of last file status change */
     off_t    st_size;   /* file size, in bytes */
     quad_t   st_blocks; /* blocks allocated for file */
     u_long   st_blksize;/* optimal file sys I/O ops blocksize */
     u_long   st_flags;  /* user defined flags for file */
     u_long   st_gen;    /* file generation number */
 };
Janne Pikkarainen
  • 8,015
6

Combing Janne and Gordon's answers:

Calling stat without flags:

$ stat Report.docx 
234881026 23858800 -rw-r--r-- 1 will staff 0 176083 "Apr 29 11:44:25 2012" "Apr 29 11:14:56 2012" "Apr 29 11:14:56 2012" "Apr 27 19:22:39 2012" 4096 344 0 Report.docx

Calling stat -x gives human-readable labels, but only defines 3 of the 4 dates:

$ stat -x Report.docx 
  File: "Report.docx"
  Size: 176083       FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (  501/    will)  Gid: (   20/   staff)
Device: 14,2   Inode: 23858800    Links: 1
Access: Sun Apr 29 11:44:25 2012
Modify: Sun Apr 29 11:14:56 2012
Change: Sun Apr 29 11:14:56 2012

Calling stat -s gives us a better answer:

$ stat -s Report.docx 
st_dev=234881026 st_ino=23858800 st_mode=0100644 st_nlink=1 st_uid=501 st_gid=20 st_rdev=0 st_size=176083 st_atime=1335663865 st_mtime=1335662096 st_ctime=1335662096 st_birthtime=1335518559 st_blksize=4096 st_blocks=344 st_flags=0

Here we see the four dates: st_atime, st_mtime, st_ctime, st_birthtime.

st_birthtime is missing from the verbose (-x) output - and for me, this matches the created date that the Finder shows.

Looking at the man page, the second documented struct (when _DARWIN_FEATURE_64_BIT_INODE is defined) shows the four dates, and defines them below.

 The time-related fields of struct stat are as follows:

 st_atime         Time when file data last accessed.  Changed by the mknod(2), utimes(2) and read(2)
                  system calls.

 st_mtime         Time when file data last modified.  Changed by the mknod(2), utimes(2) and write(2)
                  system calls.

 st_ctime         Time when file status was last changed (inode data modification).  Changed by the
                  chmod(2), chown(2), link(2), mknod(2), rename(2), unlink(2), utimes(2) and write(2)
                  system calls.

 st_birthtime     Time of file creation. Only set once when the file is created. This field is only
                  available in the 64 bit inode variants. On filesystems where birthtime is not avail-
                  able, this field holds the ctime instead.

So, depending on your architecture, the fourth date is either creation date (when 64-bit) or a duplicated ctime

brass-kazoo
  • 161
1

The output of stat(1) will differ depending on whether the system/filesystem is 64-bit or 32-bit. (If you get back 4 datetimes, it's 64 bit).

The man page for stat(2) and lstat(2) (the latter of which stat(1) actually uses by default) shows all the fields, but for some reason, stat(1) simply does not return them in the same order as listed there.

It appears the order of stat(1) without options is:

  • Device ID
  • Inode number
  • Permissions (mode)
  • Hard link count (usually 1)
  • File userid (owner)
  • File groupid
  • Device ID
  • Size in bytes
  • Last access time
  • Last (contents) modification time
  • Last permissions change time
  • Create time
  • Ideal block size for file
  • 512-byte-size blocks allocated for file
  • Flags set on file (see chflags(2))
Keith Tyler
  • 111
0

Compare the output of stat -r (prints the info in "raw" form, e.g. times in seconds since the epoch) with stat -s (with labels, suitable for setting shell variables). If I parse this out right (using OS X v10.6), the fields are: device number, inode number (/file ID number), permissions mode, link count, owner, group, rdev (device for character and block special files), size in bytes, access time, modify time, change time, birth (i.e. inode creation) time, block size, number of blocks, file flags, and finally name (/path).

Note that not all of the times will be tracked on non-OS X-native filesystems (i.e. not HFS+ or HFSX); for files accessed over SMB, I'd expect some of the reported times to be made up.

Gordon Davisson
  • 36,087