Я столкнулся со странной проблемой с rsync (без -c , следовательно, с использованием алгоритма "быстрой проверки") rsync, снова и снова копируя уже синхронизированные файлы на диск в формате exFAT.
Соответствующие исходные файлы хранятся на томе HFS и были созданы с помощью автоматического процесса извлечения изображений из текстовых документов .docx и их время модификации составляет 1 января 1980 г. 00:00:00, что также является минимальным временем, поддерживаемым формат временной метки exFAT.
После rsync -a эти файлы назначения в exFAT имеют время модификации 1 января 1980 года 02:00:00.
Похоже, что минимальное время, поддерживаемое моим драйвером OS X exFAT, отключено на два часа.
И это причина, по которой алгоритм быстрой проверки rsync считает, что файлы разные.
Следующий тест, кажется, подтверждает это:
# create a 10Mb exFAT disk image:
hdiutil create -size 10m -fs ExFAT -volname EXFATTEST exfattest.dmg
# attach the diskimage
hdiutil attach exfattest.dmg
# create a test file with a creation time of Jan 1, 1980 00:00:00
touch -t "198001010000.00" /Volumes/EXFATTEST/test1.txt
ls -lT /Volumes/EXFATTEST/test1.txt
-rwxrwxrwx 1 user staff 0 Jan 1 02:00:00 1980 /Volumes/EXFATTEST/test1.txt
# ^^ off by two hours
# try a file with 3am
touch -t "198001010300.00" /Volumes/EXFATTEST/test2.txt
ls -lT /Volumes/EXFATTEST/test2.txt
-rwxrwxrwx 1 user staff 0 Jan 1 03:00:00 1980 /Volumes/EXFATTEST/test2.txt
# ^^ works as expected
# unmount the disk image
hdiutil detach /Volumes/EXFATTEST/
Эквивалентный тест на Linux не показывает эту ошибку:
truncate -s 10M exfattest.img
mkfs.exfat exfattest.img
mkdir /mnt/EXFATTEST/
mount -o loop exfattest.img /mnt/EXFATTEST/
touch -t "198001010000.00" /mnt/EXFATTEST/test.txt
ls --full-time /mnt/EXFATTEST/test.txt
rwxr-xr-x 1 root root 0 1980-01-01 00:00:00.000000000 +0100 /mnt/EXFATTEST/test.txt
# ^^ correct modification time
umount /mnt/EXFATTEST/
Мое простое решение - обновить время создания исходных файлов, используя touch .
Тем не менее, я хотел бы знать, действительно ли это ошибка, и может ли кто-то воспроизвести эту ошибку на более новых выпусках OS X, так как Apple не позволяет обновить мой iMac, работающий в начале 2008 года;)
Я все еще на Эль-Капитане:
sw_vers
ProductName: Mac OS X
ProductVersion: 10.11.6
BuildVersion: 15G22010
Обновить:
После проверки таблицы exFAT кажется, что мой драйвер ex Capati El Capitan всегда использует 0xfc для поля данных LastModifiedTimezoneOffset .
Это значение байта со знаком указывает смещение от UTC с шагом 15 минут. 0xfc это -4 в десятичном виде и будет интерпретироваться как отрицательное смещение UTC на один час.
Я не знаю, почему драйвер делает это, но если он использует статическое смещение часового пояса -1, ему также всегда нужно будет вычесть 1 час из соответствующей метки времени UTC при сохранении временной метки и добавить 1 час к сохраненному значению, когда чтение метки времени с диска.
Это в основном работает, если только отметка времени UTC моложе 1 января 1980 года 01:00, поскольку минимальная поддерживаемая отметка времени файла в exFAT - 1 января 1980 года 00:00.
Поэтому я считаю это ошибкой, так как драйвер exFAT от El Capitan не может установить минимально возможную метку времени изменения файла, поддерживаемую exFAT.
Следующий тест, кажется, подтверждает это. Он использует переменную среды TZ для принудительного использования часового пояса UTC независимо от часового пояса системы:
# set the minimum possible exFAT file modifification timestamp in UTC
TZ=UTC touch -t '198001010000.00' /Volumes/EXFATTEST/test.txt
# read back the stored timestamp in UTC
TZ=UTC ls -lT /Volumes/EXFATTEST/test.txt
-rwxrwxrwx 1 gollum staff 0 Jan 1 01:00:00 1980 /Volumes/EXFATTEST/test.txt
# ^^^^^^^^ ERROR: off by one hour
Та же ошибка при создании файла с этой датой в HFS и копировании его на том exFAT:
# set Jan 1, 1980 00:00:00 on HFS (e.g. file in home directory)
TZ=UTC touch -t '198001010000.00' $HOME/test2.txt
TZ=UTC ls -lT $HOME/test2.txt
-rw-r--r-- 1 gollum staff 0 Jan 1 00:00:00 1980 /Users/gollum/test2.txt
# ^^^^^^^^ CORRECT!
# copy the file to the exFAT volume and check the destination date
cp -a $HOME/test2.txt /Volumes/EXFATTEST/test2.txt
TZ=UTC ls -lT /Volumes/EXFATTEST/test2.txt
-rwxrwxrwx 1 gollum staff 0 Jan 1 01:00:00 1980 /Volumes/EXFATTEST/test2.txt
# ^^^^^^^^ ERROR: off by one hour
Еще один интересный тест, который я сделал, - это взять образ диска exFAT, созданный в Linux (который содержит тестовый файл с правильной отметкой времени), и смонтировать его в OS X:
TZ=UTC ls -lT
total 0
-rwxrwxrwx 1 gollum staff 0 Jan 1 00:00:00 1980 test.txt
# ^^^^^^^^ correct!
Однако при дублировании этого файла дата снова отключается на один час. Поэтому, по крайней мере, драйвер OS X exFAT способен правильно читать метки времени, даже если файлы хранятся с использованием смещения часового пояса, отличного от 0xfc . Ура!
Теперь наоборот: монтирование OS X dmg в Linux выявляет вторую ошибку драйвера OS X exFAT:
mount -o loop exfattest.dmg /mnt/EXFATTEST/
FUSE exfat 1.0.1
ERROR: bad date 1980-01-00
# ^^^ OS X stored the DAY as zero ::facepalm::
Еще один прекрасный пример отсутствующих тестов в разработке.
Это в основном ответ на мой вопрос. Тем не менее, я приму ответ, который подтвердит мои выводы неверно или подтвердит их, а также ответит на мой вопрос, если эта ошибка также возникнет в более новых версиях, чем El Capitan OS X.
Обновление 2:
Я наткнулся на сообщение в блоге Адама Харрисона (криминалист по цифровым исследованиям из Великобритании): поведение временных меток exFAT, связанное с различными операционными системами
Цитирование:
Ubuntu 16.04 и Ubuntu 18.04
Все часовые пояса записываются в UTC. Поля часового пояса постоянно установлены на 00, что указывает на то, что они не используются.OSX 10.13.3
Поля часового пояса - последовательно установлен на «FC», который является UTC-1, и я понятия не имею, почему ...
Так что это похоже на мои выводы.