Mac OS X 10.6 / usr / bin / stat-Befehl. Wie wird die Standardausgabe angezeigt?

7573
user33688

Wenn ich den Befehl stat ausführe, wie wird die Ausgabe tatsächlich angezeigt? Ich weiß, dass Sie das Format angeben können, aber ich habe Probleme mit rsync von OS X zu NetApp SMB und versuche herauszufinden, was ist und was nicht.

# 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 

Und dies ist die Kopie, die auf das SAN synchronisiert wird.

# 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 

Meine Vermutung zum Ausgabeformat lautet:

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

Ich denke mal, drei von ihnen müssen atime, mtime und ctime sein, aber warum gibt es eine vierte und welche ist welche?

5

4 Antworten auf die Frage

9
Janne Pikkarainen

Ich bin kein OS X-Benutzer, aber ich kenne FreeBSD. Die Statistikausgabe damit sieht genauso aus wie Ihre, aber wenn Sie die Dinge klarstellen wollen, damit sie für Menschen lesbar sind, verwenden Sie stat -x your_path.

Oh, was sind das für Felder? Vielleicht hilft dieses Snippet aus der Dokumentation zu OS X :

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 */ }; 
6
brass-kazoo

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

1
Keith Tyler

Die Ausgabe von stat (1) hängt davon ab, ob das System / Dateisystem 64-Bit oder 32-Bit ist. (Wenn Sie 4 Datumsangaben zurückbekommen, sind es 64 Bit).

Die Manpage für stat (2) und lstat (2) (letzterer von denen stat (1) standardmäßig verwendet wird) zeigt alle Felder an, aber stat (1) gibt sie aus irgendeinem Grund einfach nicht in derselben Reihenfolge zurück wie dort aufgeführt.

Es scheint, dass die Reihenfolge von stat (1) ohne Optionen lautet:

  • Geräte ID
  • Inode-Nummer
  • Berechtigungen (Modus)
  • Hardlink-Anzahl (normalerweise 1)
  • Dateianwender (Besitzer)
  • Dateigruppen-ID
  • Geräte ID
  • Größe in Bytes
  • Letzte Zugriffszeit
  • Letzte (inhaltliche) Änderungszeit
  • Letzte Berechtigungsänderungszeit
  • Zeit schaffen
  • Ideale Blockgröße für die Datei
  • 512-Byte-Blöcke für Datei zugewiesen
  • Flags in der Datei (siehe Chflags (2))
0
Gordon Davisson

Vergleichen Sie die Ausgabe von stat -r(druckt die Informationen in "roher" Form, z. B. seit der Epoche in Sekunden) mit stat -s(mit Beschriftungen, geeignet zum Einstellen von Shell-Variablen). Wenn ich dies richtig auschecke (mit OS X 10.6), sind die Felder: Gerätenummer, Inode-Nummer (/ Datei-ID-Nummer), Berechtigungsmodus, Anzahl der Verknüpfungen, Besitzer, Gruppe, rdev (Gerät für Zeichen- und Block-Spezialdateien ), Größe in Bytes, Zugriffszeit, Änderungszeit, Änderungszeit, Geburtszeit (dh Inode-Erstellung), Blockgröße, Anzahl der Blöcke, Dateiflaggen und schließlich Name (/ Pfad).

Beachten Sie, dass nicht alle Zeiten auf Nicht-OS X-nativen Dateisystemen (dh nicht HFS + oder HFSX) verfolgt werden. Für Dateien, auf die über SMB zugegriffen wird, würde ich erwarten, dass einige der berichteten Zeiten aufgeholt werden.