Re: Аналог offline files от MS
On Fri, Nov 03, 2006 at 12:28:03PM +0300, Artem Chuprina wrote:
> >> Пользуюсь. Регулярно. Но не в ситуации с переименованием
> >> каталогов. Я очень не уверен, что он отреагирует на это адекватно.
> >> Впрочем, а ты пойди попробуй это сделать в гетерогенной сети, где на
> >> исходном и целевом томах файловые системы с несовместимой
> >> семантикой...
>
> DVI> Судя по доке он пишет inode для каждого файла. Так что в между
> DVI> никсами должно бы прокатывать. Блин! Неужто на эксперимент не
> DVI> тянет? :) С двумя тестовыми каталогами.
>
> Между юниксами с шансами будет. Но в обсуждаемой задаче оно отнюдь не
> между юниксами...
1. Начальная задача ставилась "аналог MS offline files под linux". Я
понял ее в "широком" смысле - хотя бы с одной стороны стоит linux.
2. Задача синхронизации (если была синхронизация) разбиваема на два
этапа:
а) Найти файлы, которые изменились с момента предыдущей синхронизации на
каждой из систем.
б) Отследить конфликты (пересечение этих списков).
При решении этапа (а) важно какая система "здесь" или "там" при создании
соответствующего списка (когда мы ищем файлы измененные с момента
окончания синхронизации на своей системе нам нет смысла учитывать
поведение удаленной системы и наоборот). Переименование каталогов на
linux (posix-системе, в которой rename помечает для обновления
ctime) мы тоже можем отследить (чего не делает мой скрипт, но что
возможно добавить). Естественно fs должна быть не FAT (там нету inodes).
Если каталог по сочетанию путь и inode number изменен, и в нем есть хотя
бы один файл с ctime меньше, чем время предыдущей синхронизации, то по
совпадению inode, записанного в snapshoot, и inode, наблюдаемого сейчас
мы можем установить соответствие между именем на "сейчас", и именем на
"прошлый раз".
> modification time. Единственное, кстати, время, которое бывает и в
> юниксовой fs, и в виндовой. Впрочем, даже в этой ситуации они различны,
> кажется - винда вроде бы ухитряется и туда написать местное время.
Для FAT - местное. Насчет ntfs - не знаю. Насчет "и" ... "и" я уже
написал выше. А различны - да, безусловно. В dos был шаг времени в 2
секунды, в ntfs время - в миллисекундах. Только (еще раз) это определяет
метод поиска обновленных файлов на одной из систем, а сочетание выносимо
за скобки.
Ну а насчет mtime это, понятно дело, с моей точки зрения негодный метод
для posix - системы.
============
Лирическое отступление для тех, кто не интересовался вопросом об
обнаружении изменений в файловой системе между запусками некоего
приложения (для POSIX-систем).
С каждым файлом связаны 3 timestamp-а:
atime, который помечается для обновления каждый раз когда
производится доступ к файлу (на чтение).
mtime, который помечается для обновления при записи в файл (усечение
файла тоже считается записью).
ctime, который помечается для обновления при "изменении атрибутов файла"
(в широком смысле, как изменение данных, так и изменение
владельца, прав доступа, atime,mtime, числа ссылок на файл).
Это если грубо и упрощенно. Вообще могу привести табличку на эту тему.
Функция stat приводит к обновлению любого timestamp-а, помеченного для
обновления.
Увидев подобное вышеописанному в man stat многие полагают достаточным
для получения списка файлов, изменившихся с момента t0, использовать
find или что-то в этом роде. И тут они часто делают ошибку.
С бытовой пользовательской точки зрения файл - именованный контейнер на
диске. Но с точки зрения системы это не так. Имя файла с ее точки зрения
лишь ссылка на этот файл. И эта ссылка тоже может измениться при
переименовании самого файла или родительского каталога (или
родительского каталога родительского каталога, или ...).
И тут нельзя не упомянуть о том, что для вызова rename в стандарте POSIX
оговорено, что он должен помечать для обновления ctime и mtime
родительского каталога, но про сам файл сказано, что это implementation
dependant.
В зависимости от того как этот вызов себя ведет (обновляет ctime самого
файла или нет) вырисовываются 2 случая:
1. ctime обновляется: тогда изменение имени самого файла мы увидим через
stat, и нам нужен дополнительный механизм лишь для
того, чтобы отследить переименование родительского
каталога или его родителей.
2. ctime не обновляется: для отслеживания любого переименования нужен
внешний механизм.
Сей дополнительный механизм использует то, что у файла есть inode number
(file serial number) - уникальный идентификатор файла, который уникален
в пределах файловой системы и не меняется пока файл существует.
Запомнив соответствие между файлом и его inode number мы сможем точно
сказать изменилось имя файла (в смысле ссылка на файл) или нет.
Для второго случая все ясно. Для первого случая стоит упомянуть о том,
что если каталог был удален, после чего создан новый с тем же именем и
он по совпадению получил такой же inode number как и у старого - этот
каталог пуст, и коль скоро ctime при переименовании самого файла
обновляется - все файлы, для которых этот каталог является
непосредственным предком будут иметь ctime больший, чем t0.
=========
Впрочем я, как аццкий сотона, видимо всем уже поднадоел :))))
WBR
Dmitri Ivanov
Reply to: