Сисадмин-любитель (ulrith) wrote,
Сисадмин-любитель
ulrith

синхронизация файлов

Если работаешь не только на работе, но и дома, возникает необходимость синхронизации файлов. Помниццо в своё время я ещё на Виндоз интересовался эконкой "Портфель", но как ей пользоваццо так и ниасилил.

Вообще-то для этой цели в unix-мире существует мощная утилита rsync, но мне её осваивать было лень и поэтому я прошёл путь ошибок трудный, который и опишу.

Сначала я прочитал man стандартной unix-команды cp и написал следующий скрипт:

#!/bin/sh
cp -pur /там/* /здесь


Данная команда копирует содержимое одного каталога (там) в другой каталог (здесь), сохраняя атрибуты файлов (например, дату создания) и копируя не все, а только те из них, у которых дата изменения новее. "Зачем мне этот rsync, когда всё так просто!" - думал я.

Однако со временем я понял, зачем. Сначала возникла проблема, о которой я написал в коммьюнити ru_ubuntu. При разрыве коннекта во время синхронизации по sshfs в каталогах образовывались недокачанные файлы нулевой длины со свежей датой, которые затем затирали нормальные.

Поскольку решения в рамках тюнинга команды cp не нашлось, я придумал workaround (а скорее даже не workaround, а просто альтернативное решение):

#!/bin/sh
find /там -size 0 -type f -print0 | xargs -0 /bin/rm -f
cp -pur /там/* /здесь


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

Со временем я отказался от синхронизации по сети и стал таскать файлы туда-сюда на флэшке/внешнем харде. При этом файловая система на носителе оказывалась то FAT32, то вообще NTFS (переформатировать на ext3 мне её было лень)... Из-за этого при копировании файлов в терминале начинали лезть противные сообщения о невозможности скопировать владельца и режим доступа к файлам (которые, вместе с временными метками, по умолчанию копирует "cp -p"). Пытаясь избавиццо от этих сообщений, я необдуманно отключил опцию -p в команде cp, вследствие чего выплеснул с молоком и ребёнка: результат очередной синхронизации оказался дефектным: были потеряны даты создания файлов и каталогов. А эта информация, по моему рабочему опыту, куда как* полезна для выяснения того, какая версия присланных по e-mail файлов самая последняя (без тугодумного открытия этих самых файлов).

В общем, вследствие этой слабоумной ошибки я оказался у разбитого корыта: последняя копия синхронизируемых данных оказалась испорчена (все файлы и каталоги имели текущую дату), а старая версия из бэкапа не содержала последних обновлений. Что же делать? Ведь теперь любая попытка синхронизации просто перезапишет все старые файлы с правильными датами новыми! Изучение опций команды "cp" не дало зацепок в поиске выхода из сложившейся ситуации.

И тут-то мне и помог rsync, который я по-прежнему ленюсь изучать. Беглое знакомство с man-ом показало, что в этой утилите есть бесценная опция "-c", которая позволяет обновлять файлы на основе не даты их изменения, а checksum! Это позволило мне восстановить правильные даты файлов хотя бы для тех из них, которые были в бэкапе...

Ну а от противных сообщений об ошибках копирования атрибутов файлов мне удалось избавиццо малой кровью: опцию -p я заменил на --preserve=timestamps, что позволило копировать только даты изменений файлов, которые, слава богу, сохраняюццо в любой файловой системе - хоть даже FAT16.

Ну и напоследок - прикольный способ радостно пикнуть когда операция копирования файлов успешно завершена. Для этого нужно вставить в скрипт команду:

tput bel

В следующий раз расскажу про общую папку по протоколу NFS и umask.

* - И чего это в последнее время журналисты так полюбили это выражение: "куда как"? Вот и я закудахтал...
Tags: unixway
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 4 comments