Просто для тестирования Вы попытались отключить пропускную способность, регулирующую в целом?
http://blogs.technet.com/b/filecab/archive/2006/06/14/434190.aspx
Также проверьте свои настройки подготовки дважды. Больше информации здесь о надлежащем вычислении подготовки
http://blogs.technet.com/b/filecab/archive/2006/03/20/422544.aspx
В конечном итоге я не смог найти способ получить --listed-incremental работу с Dropbox. Я предполагаю, как сказал Вениамин, tar смотрит и на ctime, и на mtime. Dropbox должен делать что-то, что касается ctime, поэтому он просто заставляет весь архив копироваться каждый раз, когда я его запускаю.
Вместо этого я просто сделал tar --create --file mybackup.tar --newer-mtime = "26 января 2013 г." Dropbox
Хотя это не так гладко, как инкрементное резервное копирование, я доволен им, поскольку он должен получить все файлы которые изменились (на основе mtime) с момента моей последней резервной копии. В этом случае эта резервная копия является третьей резервной копией, поэтому, если что-то случится там, где я доберусь до этой, я буду счастлив просто иметь файлы, и работа с не совсем гладкой системой будет в порядке. ] Спасибо за ваши ответы.
Вы не упомянули файловую систему / тип устройства, но вы можете попробовать:
$ tar --create --no-check-device --file=dropbox_incremental_1.tar --listed-incremental=dropbox_0.snar Dropbox
См. также Исправление файлов моментальных снимков .
Tar действительно выглядит mtime. Но он также должен выглядеть ctime, поскольку он обрабатывает метаданные файла (например, разрешения).
Я предполагаю, что ваше приложение Dropbox использует ctime для своих собственных целей, и вы ничего не можете с ним поделать.
UPD:
Вы может использовать параметр обновления -u вместо инкрементного режима. Похоже, что время игнорируется.