2

Я хотел бы получить миллисекунды со времени создания атрибута файла Когда я получаю атрибут файла, я использую NSDateFormatter для преобразования времени создания файла (NSDate) в NSString.Атрибут файла содержит миллисекунду? Objective -c

[dateFormatter setDateFormat: @ "yyyy-MM-dd HH: mm: ss: SS: A"];

  • сс -> секунд
  • SS -> должны быть миллисекунды
  • А -> миллисекунды даты

я 00 для СС и получить 54487000 для А. Я замечаю, что последние три цифры всегда равны нулю для NSDate, поступающих из атрибута файла любых файлов. Но когда я использую тот же форматтер с NSDate, который приходит из [NSDate date], последние три цифры не равны нулю для A, а цифра SS не всегда равна нулю.

Атрибут файла, полученный в Objective c, содержит атрибут файла?

+1

Зачем нужна эта точность? Просто спрашиваю. –

+1

Например, чтобы увидеть, какой из нескольких файлов, которые были изменены за одну секунду, был изменен последним (например, для генерации файлов N-1 на основе содержимого N-го файла) –

ответ

3

Это может зависеть от того, в какой операционной системе вы находитесь, и в какой файловой системе находится файл. Я предполагаю, что вы на iOS (в этом случае вы используете любую файловую систему iOS, которая используется).

Системный вызов stat возвращает информацию о файле, включая несколько временных меток, в структуре, называемой struct stat. Структура хранит каждую метку времени как struct timespec. struct timespec содержит поле секунд tv_sec и поле наносекунд tv_nsec. Поэтому теоретически вы можете получать отметки времени наносекундного разрешения для ваших файлов.

На практике похоже, что вы получаете только временные метки второго разрешения. Я тестировал с этим кодом:

struct stat sb; 
stat([NSBundle.mainBundle pathForResource:@"Info" ofType:@"plist"].UTF8String, &sb); 

на моем iPhone 4S под управлением IOS 5.0.1, и получил этот результат:

(gdb) p sb 
$1 = { 
    st_dev = 234881033, 
    st_mode = 33188, 
    st_nlink = 1, 
    st_ino = 11265454, 
    st_uid = 501, 
    st_gid = 20, 
    st_rdev = 0, 
    st_atimespec = { 
    tv_sec = 1330753666, 
    tv_nsec = 0 
    }, 
    st_mtimespec = { 
    tv_sec = 1330753664, 
    tv_nsec = 0 
    }, 
    st_ctimespec = { 
    tv_sec = 1330753664, 
    tv_nsec = 0 
    }, 
    st_birthtimespec = { 
    tv_sec = 1330417559, 
    tv_nsec = 0 
    }, 
    st_size = 830, 
    st_blocks = 8, 
    st_blksize = 4096, 
    st_flags = 0, 
    st_gen = 0, 
    st_lspare = 0, 
    st_qspare =  {0, 
    0} 
} 

Вы можете увидеть, что все tv_nsec полей равны 0. Это кажется маловероятным быть совпадением.

Исторически HFS Plus (родная файловая система Mac OS X, вероятно, используемая iOS также) хранила каждую временную метку в 32-разрядном беззнаковом целое, представляющем количество секунд с полуночи 1 января 1904 года по Гринвичу. (См. Technical Note TN1150.) Предположительно, в какой-то момент они увеличили временные метки до 64 бит (или сделают это до 2040 года, когда будут разбиты 32-битные временные метки), но, по-видимому, они не добавили никаких дробных бит.

Смежные вопросы