Команда Mac OS X 10.6 / usr / bin / stat, що мені показує вихід за замовчуванням?


5

Коли я запускаю команду stat, що насправді показує вихід? Я знаю, що ви можете вказати формат, але я усуваю проблеми з rsync від OS X до NetApp SMB і намагаюся розробити те, що є, а що не копіює.

# 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

І це копія rsync'ed до САН ..

# 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

Я здогадуюсь про вихідний формат це ..

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

Що стосується часів, то, мабуть, три з них мають бути atime, mtime та ctime, але чому існує четвертий, а який - який?

Відповіді:


9

Я не користувач ОС X, але я знайомий з FreeBSD. Вихід статистики з ним виглядає так само, як і у вас, але якщо ви хочете уточнити, чи можна зрозуміти людину, використовуйте stat -x your_path.

О, які це поля? Можливо, цей фрагмент із документації на 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

Поєднання відповідей Дженни та Гордона:

Дзвінки statбез прапорців:

$ 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

Виклик stat -xдає зрозумілі людині мітки, але визначає лише 3 з 4 дат:

$ 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

Дзвінок stat -sдає нам кращу відповідь:

$ 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

Тут ми бачимо чотири дати: st_atime, st_mtime, st_ctime, st_birthtime.

st_birthtimeвідсутній у -xвисновку verbose ( ) - і для мене це відповідає createdдаті, яку показує Finder.


Переглядаючи сторінку чоловіка , друга задокументована структура ( when _DARWIN_FEATURE_64_BIT_INODE is defined) показує чотири дати та визначає їх нижче.

 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.

Отже, залежно від вашої архітектури, четверта дата є або датою створення (коли 64-бітна), або дублюється ctime


1

Вихід stat (1) буде відрізнятися залежно від того, система / файлова система 64-бітна або 32-бітна. (Якщо ви отримаєте 4 дати, це 64 біт).

Сторінка man для stat (2) та lstat (2) (останній з яких stat (1) фактично використовує за замовчуванням) показує всі поля, але чомусь stat (1) просто не повертає їх у тому ж порядку як зазначено там.

Здається, порядок stat (1) без опцій:

  • Ідентифікатор пристрою
  • Номер вводу
  • Дозволи (режим)
  • Кількість жорстких посилань (зазвичай 1)
  • Файл userid (власник)
  • Файл групи
  • Ідентифікатор пристрою
  • Розмір у байтах
  • Останній час доступу
  • Останній (зміст) час модифікації
  • Останні дозволи змінити час
  • Створіть час
  • Ідеальний розмір блоку для файлу
  • Блоки розміру 512 байтів, виділені для файлу
  • Файли встановлені у файлі (див. Chflags (2))

0

Порівняйте вихід stat -r(друкує інформацію у "сировинній" формі, наприклад, раз у секундах з епохи) з stat -s(з мітками, що підходять для встановлення змінних оболонок). Якщо я розбираю це правильно (використовуючи OS X v10.6), поля полягають у: номера пристрою, номера inode (/ ідентифікаційний номер файла), режиму дозволів, кількості посилань, власника, групи, rdev (пристрій для символів та блокування спеціальних файлів ), розмір у байтах, час доступу, зміна часу, зміна часу, час народження (тобто створення inode), розмір блоку, кількість блоків, прапори файлів та нарешті назва (/ шлях).

Зауважте, що не всі часи будуть відстежуватися в файлових системах, що не належать до ОС X (тобто не HFS + або HFSX); для файлів, доступ до яких здійснюється через SMB, я б очікував, що деякі звітних часів будуть складені.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.