Вопросы Теги

Несоответствие в измененное/созданное/полученное доступ время на Mac

Я испытываю затруднения с помощью os.utime правильно установить время изменения на Mac (Mac OS X 10.6.2, под управлением Python 2.6.1 от /usr/bin/python). Это не согласовывается с touch утилита, и это не согласовывается со свойствами, отображенными в Средстве поиска, "получают информацию" окно.

Рассмотрите следующую последовательность команды. 'Созданные' и 'измененные' времена в простом тексте относятся к атрибутам, показанным в, "получают информацию" окно в средстве поиска. Как напоминание, os.utime берет аргументы (filename, (atime, mtime)).

>>> import os
>>> open('tempfile','w').close()

'созданный' и 'измененный' оба текущее время.

>>> os.utime('tempfile', (1000000000, 1500000000) )

'созданный' текущее время, 'измененный' 13 июля 2017.

>>> os.utime('tempfile', (1000000000, 1000000000) )

'созданный' и 'измененный' оба 8 сентября 2001.

>>> os.path.getmtime('tempfile')
1000000000.0
>>> os.path.getctime('tempfile')
1269021939.0
>>> os.path.getatime('tempfile')
1269021951.0

... но os.path.get?time и os.stat не отражайте его.

>>> os.utime('tempfile', (1500000000, 1000000000) )

'созданный' и 'измененный' все еще оба 8 сентября 2001.

>>> os.utime('tempfile', (1500000000, 1500000000) )

'созданный' 8 сентября 2001, 'измененный' 13 июля 2017.

Я не уверен, является ли это проблемой Python или проблемой статистики Mac. Когда я выхожу из оболочки Python и работаю

touch -a -t 200011221234 tempfile

ни модификация, ни времена создания не изменяется, как ожидалось. Затем я работаю

touch -m -t 200011221234 tempfile

и оба 'созданных' и 'измененных' раза изменяются.

У кого-либо есть какая-либо идея, что продолжается? Как я последовательно изменяю времена модификации и создания на Mac? (Да, я знаю что в системах Unixy нет никакого "времени создания".)

Результат запущения скрипта Chris Johnsen:

seth@local:~$ /usr/bin/python timetest.py tempfile 5
initial:
(1269631281.0, 1269631281.0, 1269631281.0, 1269631281, 1269631281, 1269631281)

test: (1000000000, 1000000000)
(1000000000.0, 1000000000.0, 1269631281.0, 1000000000, 1000000000, 1269631281)
(1269631281.0, 1000000000.0, 1269631281.0, 1269631281, 1000000000, 1269631281)

test: (1000000000, 1500000000)
(1000000000.0, 1500000000.0, 1269631286.0, 1000000000, 1500000000, 1269631286)
(1269631286.0, 1500000000.0, 1269631286.0, 1269631286, 1500000000, 1269631286)

test: (1500000000, 1000000000)
(1500000000.0, 1000000000.0, 1269631291.0, 1500000000, 1000000000, 1269631291)
(1269631291.0, 1000000000.0, 1269631291.0, 1269631291, 1000000000, 1269631291)

test: (1500000000, 1500000000)
(1500000000.0, 1500000000.0, 1269631296.0, 1500000000, 1500000000, 1269631296)
(1269631296.0, 1500000000.0, 1269631296.0, 1269631296, 1500000000, 1269631296)

В конце осуществления 'созданная' дата как видимая в средстве поиска является 08.09.01, и 'измененная' дата является 13.07.17. (Дата доступа, благодаря, по-видимому, высвечивают, как Вы предполагаете и поскольку я читал о, примерно 'теперь'.) созданные и измененные даты, видимые в средстве поиска все еще, не имеют никакого смысла.

6
задан Seth Johnson 26 March 2010 в 19:32
поделиться

2 ответа

POSIX atime , mtime , ctime

Это может помочь, если вы включите полный сценарий и его фактические и ожидаемые результаты вместо фрагментов REPL. 

import sys, os, stat, time

def get_times(p):
    s = os.stat(p)
    return ( 
        os.path.getatime(p),
        os.path.getmtime(p),
        os.path.getctime(p),
        s[stat.ST_ATIME],
        s[stat.ST_MTIME],
        s[stat.ST_CTIME],
    )

def main(p, delay=1):
    delay = float(delay)
    (a,b) = (1000000000, 1500000000)

    open(p,'w').close()

    print 'initial:'
    print get_times(p)

    for t in [ (a,a), (a,b), (b,a), (b,b) ]:
        print
        print 'test:', t
        os.utime(p,t)
        print get_times(p)
        time.sleep(delay)
        print get_times(p)

main(*sys.argv[1:])

Я получаю это в своей системе 10.4 с помощью cd "$ HOME" && python test.py tempfile 5 (Python 2.3.6 по умолчанию в системе и Python 2.6.4 для MacPorts дают одинаковый результат (исключая начальные времена и ctime , конечно)): 

% python /tmp/test.py tempfile 5
initial:
(1000000000.0, 1000000000.0, 1269629881.0, 1000000000, 1000000000, 1269629881)

test: (1000000000, 1000000000)
(1000000000.0, 1000000000.0, 1269629881.0, 1000000000, 1000000000, 1269629881)
(1000000000.0, 1000000000.0, 1269629881.0, 1000000000, 1000000000, 1269629881)

test: (1000000000, 1500000000)
(1000000000.0, 1500000000.0, 1269629886.0, 1000000000, 1500000000, 1269629886)
(1000000000.0, 1500000000.0, 1269629886.0, 1000000000, 1500000000, 1269629886)

test: (1500000000, 1000000000)
(1500000000.0, 1000000000.0, 1269629891.0, 1500000000, 1000000000, 1269629891)
(1500000000.0, 1000000000.0, 1269629891.0, 1500000000, 1000000000, 1269629891)

test: (1500000000, 1500000000)
(1500000000.0, 1500000000.0, 1269629896.0, 1500000000, 1500000000, 1269629896)
(1500000000.0, 1500000000.0, 1269629896.0, 1500000000, 1500000000, 1269629896)

Это кажется разумным. Интересно, что у тебя получается.

Я слышал, что Spotlight может иногда агрессивно сбрасывать atime из-за повторной индексации измененных файлов. Я не ожидал, что он повторно проиндексирует файл, который подвергся только utime () / utimes (), но я полагаю, что это возможно. Чтобы исключить Spotlight как возможное осложнение, используйте файл в месте, которое не индексируется Spotlight (например, / tmp / testfile).

Дата создания в Finder

(отображается как «Создано:» в окнах Get Info Finder)

Если у вас установлены инструменты разработчика, вы можете использовать / Developer / Tools / GetFileInfo , чтобы увидеть дату создания HFS.Я добавил следующие строки после каждой строки print get_times (p) : 

sys.stdout.flush()
os.system('/Developer/Tools/GetFileInfo ' + p)

Я также изменил итерацию, чтобы она соответствовала вашему исходному описанию ( [(a, b), (a, a), (б, а), (б, б)] ).

Результат теперь выглядит следующим образом: 

% rm /tmp/tempfile; python /tmp/test.py /tmp/tempfile 1
initial:
(1269636574.0, 1269636574.0, 1269636574.0, 1269636574, 1269636574, 1269636574)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 03/26/2010 15:49:34
modified: 03/26/2010 15:49:34

test: (1000000000, 1500000000)
(1000000000.0, 1500000000.0, 1269636574.0, 1000000000, 1500000000, 1269636574)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 03/26/2010 15:49:34
modified: 07/13/2017 21:40:00
(1000000000.0, 1500000000.0, 1269636574.0, 1000000000, 1500000000, 1269636574)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 03/26/2010 15:49:34
modified: 07/13/2017 21:40:00

test: (1000000000, 1000000000)
(1000000000.0, 1000000000.0, 1269636576.0, 1000000000, 1000000000, 1269636576)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 09/08/2001 20:46:40
modified: 09/08/2001 20:46:40
(1000000000.0, 1000000000.0, 1269636576.0, 1000000000, 1000000000, 1269636576)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 09/08/2001 20:46:40
modified: 09/08/2001 20:46:40

test: (1500000000, 1000000000)
(1500000000.0, 1000000000.0, 1269636577.0, 1500000000, 1000000000, 1269636577)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 09/08/2001 20:46:40
modified: 09/08/2001 20:46:40
(1500000000.0, 1000000000.0, 1269636577.0, 1500000000, 1000000000, 1269636577)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 09/08/2001 20:46:40
modified: 09/08/2001 20:46:40

test: (1500000000, 1500000000)
(1500000000.0, 1500000000.0, 1269636578.0, 1500000000, 1500000000, 1269636578)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 09/08/2001 20:46:40
modified: 07/13/2017 21:40:00
(1500000000.0, 1500000000.0, 1269636578.0, 1500000000, 1500000000, 1269636578)
file: "/private/tmp/tempfile"
type: ""
creator: ""
attributes: avbstclinmedz
created: 09/08/2001 20:46:40
modified: 07/13/2017 21:40:00

Похоже, это согласуется с вашими наблюдениями из окна Get Info в Finder . Моя интерпретация (подтвержденная другими экспериментами) заключается в том, что HFS creationDate обновляется utime, но всегда идет только назад (никогда не вперед). Если вы хотите обновить HFS creationDate до более нового значения, вам, вероятно, придется использовать для этого API, специфичный для Mac.

Еще одно замечание: возможно, вам придется немного переключить окна, чтобы обновить окно Get Info . В моей системе его отображение не обновляется автоматически, если я не переключу окна в окно Get Info или из него.

2
ответ дан 17 December 2019 в 20:30
поделиться

Mac OS поддерживает дополнительные атрибуты, которые не отображаются в posix.

  • createDate
  • contentModDate
  • attributeModDate
  • accessDate
  • backupDate

Раньше вы могли получить доступ к ним через старый модуль macfs, который давно устарел в пользу модуля Carbon, который в значительной степени недокументирован и теперь устарел. Я думаю, что в Carbon.File и Carbon.Folder есть то, что вам нужно. (Я недостаточно слежу за Mac, чтобы знать, каков текущий план для этих функций. Возможно, Carbon просто извлекается из stdlib, и он будет продолжаться сам по себе.)

Может быть, комментарий с подробным описанием того, что вы ищете. вместо отрицательного ответа

я не совсем уверен, какой еще согласованности вы ожидаете. Python использует posix api, а инструменты Apple используют API Apple. Кажется, что каждый из них внутренне непротиворечив, но они могут отличаться друг от друга.

  • attributeModDate отображается в ctime.
  • createDate - это то, что Finder отображает для "created"
  • Если вы измените mtime на более раннее, чем createDate, api файловой системы Mac изменит createDate на соответствие; что предотвращает несоответствие очевидной модификации перед созданием. Это устраняет единственное непоследовательное поведение, которое я могу понять из приведенного выше примера.
0
ответ дан 17 December 2019 в 20:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: