FSEvents обработка на диск, променен от друга операционна система

Виждам странно поведение на FSEvents, където монтирам устройството си в режим на възстановяване и при рестартиране получавам нула fsevents в моя поток. Правя следното:

  1. Стартирайте редовно
  2. Запишете текущото събитие с FSEventsGetCurrentEventId()
  3. Стартирайте в режим на възстановяване и модифицирайте файл в наблюдавания път
  4. Рестартирайте системата

Когато това се случи, не получавам никакви събития, когато използвам fsevents API. Единственият флаг, който изпраща в kFSEventStreamEventFlagHistoryDone sentinel, дори ако бях направил други промени в обикновената операционна система.

Този ревю на ars technica изглежда предполага, че когато монтирате на друго устройство, трябва да получите флага kFSEventStreamEventFlagMustScanSubDirs, но не виждам това поведение. Някой сблъсквал ли се е с това преди? Има ли по-добър начин за откриване и справяне със случая, че устройството е било монтирано някъде другаде, докато операционната система е била изключена?

Актуализация: Опитах същото, зареждайки от Linux и модифицирайки файловата система. Не получих същото странно поведение на 0 събития, независимо от всичко, но също така не получих събитие от директорията, която промених, или флаг MustScanSubdirs.

Актуализация 2: В тази тема приетият отговор казва, че когато това се случи , машината на времето открива, че регистрационните файлове са остарели в горните ситуации. Някой знае ли как да открия дали регистрационните файлове са остарели? Тази дата може да се използва вместо флаг.


macos fsevents
person Kat    schedule 02.09.2012    source източник

Отговори (1)


arrow_upward
2
arrow_downward

Мисля, че трябва също да съхраните UUID на базата данни FSEvents в стъпка #2 и да проверите за него в стъпка #4.

Това поведение е неясно споменато в документацията на Apple (курсивът е добавен):

Забележка: Тъй като дисковете могат да бъдат модифицирани от компютри, работещи с по-ранни версии на OS X (или потенциално други операционни системи), трябва да третирате списъка със събития като препоръка, а не като окончателен списък на всички промени в тома. Ако дискът е модифициран от компютър, работещ с предишна версия на OS X, историческият регистрационен файл се изхвърля.

Например, софтуерът за архивиране все още трябва периодично да извършва пълно почистване на произволен обем, за да гарантира, че няма промени да пропаднат през пукнатините.

Обърнете внимание на частта за изхвърлянето на историческия регистрационен файл, след което погледнете справка (курсивът е добавен):

FSEventStreamGetLatestEventId() -> Първоначално това връща стойността SinceWhen, предоставена при създаването на потока; след това той се актуализира с идентификатора на събитие с най-голям номер, споменат в текущата група от събития точно преди извикване на обратно извикване на клиента. Клиентите могат да съхраняват тази стойност постоянно, докато съхраняват и UUID за устройството (получено чрез FSEventsCopyUUIDForDevice()). След това клиентите могат по-късно да предоставят този идентификатор на събитие като параметър sinceWhen на FSEventStreamCreateRelativeToDevice(), стига неговият UUID да съвпада с това, което сте съхранили. Това работи, защото услугата FSEvents съхранява събития в постоянна база данни за обем. В това отношение потокът от идентификатори на събития действа като глобален часовник за цялата система, но няма връзка с конкретна времева база.

FSEventsCopyUUIDForDevice() -> Получава UUID, който уникално идентифицира FSEvents базата данни за този том. Ако базата данни бъде изхвърлена, нейната замяна ще има различен UUID, така че клиентите да могат да открият тази ситуация и да избегнат опитите да използват идентификатори на събития, които са съхранили като параметър SinceWhen към функциите FSEventStreamCreate...().

Имайте предвид, че UUID е за всяко устройство, така че ако имате някакви файлови системи, монтирани в дървото на вашата директория, вероятно ще трябва да получите UUID на всяка от тях.

Късмет!

person dlitz    schedule 05.09.2012