Вопрос или проблема
Я уже давно использую rsync для Android, чтобы делать резервные копии моего телефона на удаленную файловую систему NTFS на Linux-системе.
Недавно жесткий диск с файловой системой NTFS начал сбоить (или выдавать “ошибки I/O”), поэтому я воспользовался возможностью и скопировал все файлы на новый жесткий диск и новую файловую систему NTFS. В данном случае я использовал инструмент “FastCopy v2.11” для Windows.
Моя проблема в том, что когда я запускаю “dry run” с помощью rsync, я вижу, что он хочет перекопировать файлы, которые уже существуют в удаленной папке rsync. Например, когда я запускаю с параметром “-iv”, я получаю такой вывод:
<f..t...... extSdCard/foo/bar
Как я понимаю, это значит, что rsync хочет скопировать этот файл на удаленный rsync из-за разницы в метке времени.
Странно то, что когда я использую “Astro” для Android, чтобы посмотреть свойства локального файла, я вижу, что размер файла, время изменения и MD5-хэш точно такие же, как у удаленного файла (используя ls -l для проверки времени изменения).
Учитывая, что я недавно скопировал удаленные файлы rsync с старой файловой системы NTFS, ctime удаленного файла отличается (смотрел с помощью ls -lc).
Смотрит ли rsync на ctime удаленного файла, и если да, есть ли какой-то способ использовать rsync или ntfs-3g, чтобы обойти эту проблему?
По умолчанию rsync полагается на mtime/ctime и размер для сравнения файлов, но если вы используете флаг -c, он будет игнорировать их и использовать контрольные суммы содержимого.
Проблема в том, что этот способ может быть гораздо медленнее (расчет контрольных сумм может быть действительно затратным на вашем мобильном устройстве), и возможно, вам придется всегда запускать rsync так, поэтому имеет смысл просто позволить ему один раз выполниться без контрольных сумм, чтобы он скопировал все заново на основе метода сравнения mtime/ctime/размер, который он использует по умолчанию, но, по крайней мере, в следующий раз вам не придется тратить время на расчёт контрольных сумм.
Я провел небольшой эксперимент; rsync сравнивает mtime и игнорирует ctime (по крайней мере, на Mac). К сожалению, файловые системы Windows имеют только ctime, который они возвращают для atime и mtime также.
Вот почему rsync так настойчиво копирует файлы с файловых систем Windows, которые не нужно копировать — mtime на файле Unix сравнивается с “ctime” на файле Windows.
Ответ или решение
rsync — это мощный инструмент для синхронизации файлов и каталогов между различными системами, и он широко используется в различных средах, включая Linux. Однако, когда дело доходит до работы с файловыми системами, такими как NTFS, могут возникать определенные сложности, частью которых являются атрибуты времени файлов: mtime (время модификации) и ctime (время изменения).
Отличия между mtime и ctime
-
mtime (Modification Time): Это атрибут, который обновляется, когда содержимое файла изменяется. В контексте
rsync, именноmtimeиспользуется для определения необходимости копирования файла — еслиmtimeисточника отличается отmtimeназначения, файл будет скопирован. -
ctime (Change Time): Этот атрибут обновляется не только когда изменяется содержимое файла, но и когда изменяются метаданные файла, такие как права доступа или владелец. В вашей ситуации переписывания на новую NTFS файловую систему, вероятно, изменит ctime.
Проблемы с NTFS
Как упоминается, существует интересное различие между Unix-подобными системами и Windows в отношении хранения и обработки этих временных атрибутов. Windows NTFS не имеет ясной поддержки mtime в том виде, как rsync ожидает его видеть на Unix-подобных файловых системах. Поэтому оно репортирует ctime как mtime, что приводит к путанице.
Как справиться с этой проблемой
-
Использование ключа -c в rsync:
rsync -avc source/ destination/Этот флаг указывает
rsyncигнорироватьmtimeиctimeи вместо этого сравнивать содержимое файлов с помощью контрольных сумм. Однако такая операция может быть ресурсоемкой, особенно если на устройстве мало вычислительных ресурсов. -
Однократная синхронизация для обновления временных меток: Вы можете позволить
rsyncвыполнить полную синхронизацию один раз, чтобы обновить временные метки на новый диск. Это займет некоторое время, но в дальнейшем использование будет более оптимизированным, посколькуrsyncне будет повторно копировать файл из-за разницы временных атрибутов.
Заключение
В вашем случае проблема возникает из-за особенностей работы файловых систем Windows и Unix. rsync ориентирован на Unix-подобные системы и полагается на mtime, который может неправильно интерпретироваться при копировании с NTFS. Использование флага -c или выполнение полной синхронизации как временного подхода может помочь в решении данной проблемы. Выбор будет зависеть от компромисса между временем выполнения и уровнем точности, который вы хотите достичь в процессе синхронизации.
В зависимости от результатов, вы также можете рассмотреть возможность использования других инструментов, которые лучше совместимы с NTFS, если эти решения кажутся неудобными.