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 в 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

Мое предположение о выходном формате это ..

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

Что касается времени, я думаю, что три из них должны быть atime, mtime и ctime, но почему есть 4-й и какой из них какой?

4 ответа4

9

Я не пользователь OS 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) - и для меня это соответствует дате 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)
  • Идентификатор файла (владелец)
  • Файл groupid
  • Идентификатор устройства
  • Размер в байтах
  • Время последнего доступа
  • Время последнего (содержания) изменения
  • Время последнего изменения разрешения
  • Создать время
  • Идеальный размер блока для файла
  • Блоки размером 512 байт, выделенные для файла
  • Флаги, установленные в файле (см. Chflags (2))
0

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .