Блог

У меня есть существенный (~ 1 ТБ) каталог, в котором уже есть резервная копия в хранилище архива Google. Из-за нехватки места на локальном компьютере мне пришлось перенести каталог в другое место, но теперь, когда я пытаюсь запустить скрипт, который синхронизировал его с облаком (используя новый каталог в качестве источника), он пытается загрузить все. Я предполагаю, что проблема связана с временными метками в перенесенных файлах, потому что, когда я экспериментирую с « -c » (сравнение CRC), он работает нормально, но слишком медленно, чтобы быть работоспособным (даже со скомпилированным CRC).

При ручной проверке временных меток кажется, что они были скопированы хорошо (использовались robocopy /mir для миграции), так какая именно временная метка расстраивает / сбивает с толку gsutil ..?

Я вижу несколько путей выхода из этого:

1. Поиск способа сохранения исходных временных меток при копировании (у меня все еще есть исходная папка, так что это вариант)
2. Каким-то образом убедить gsutil исправлять только временные метки облачных файлов или возвращаться только к размеру
3. Стисните зубы и повторно загрузите все

Буду признателен за любые предложения.

команда, используемая для миграции:

 robocopy SOURCE TARGET /mir /unilog :robocopy.log /tee
 

Также пробовал:

 robocopy SOURCE TARGET /mir /COPY:DAT /DCOPY:T /unilog :robocopy.log /tee
 

команда, используемая для синхронизации с Google:

 gsutil -m rsync -r "source" "gs://MYBUCKET/target"
 

Получается, что даже при попытке синхронизировать временные метки они получаются разными:

 >>> os.stat(r'file.copy')
nt.stat_result(st_mode=33206, ... st_size=1220431L, st_atime=1606987626L, st_mtime=1257521848L, st_ctime=1512570325L)
>>> os.stat(r'file.original')
nt.stat_result(st_mode=33206, ... st_size=1220431L, st_atime=1606987624L, st_mtime=1257521847L, st_ctime=1512570325L)
 

можно четко видеть, что mtime и atime просто частично отключены (позже)

попытка их синхронизации:

 >>> os.utime(r'file.copy', (1606987626, 1257521847))
>>> os.stat(r'file.copy')
nt.stat_result(st_mode=33206, ... st_size=1220431L, st_atime=1606987626L, st_mtime=1257521848L, st_ctime=1512570325L)
 

в результате mtime все еще отключен, но если я вернусь немного назад во времени:

 >>> os.utime(r'file.copy', (1606987626, 1257521845))
>>> os.stat(r'file.copy')
nt.stat_result(st_mode=33206, ... st_size=1220431L, st_atime=1606987626L, st_mtime=1257521846L, st_ctime=1512570325L)
 

Он меняется, но все еще не точен.

Однако теперь, вернув его вовремя, я могу использовать переключатель « -u «, чтобы игнорировать новые файлы в пункте назначения:

 gsutil -m rsync -u -r "source" "gs://MYBUCKET/target"
 

скрипт, который исправляет временные метки для всех файлов в цели:

 import os

SOURCE = r'source'
TARGET = r'target'

file_count = 0
diff_count = 0

for root, dirs, files in os.walk(SOURCE):
    for name in files:
        file_count  = 1
        source_filename = os.path.join(root, name)
        target_filename = source_filename.replace(SOURCE, TARGET)
        try:
            source_stat = os.stat(source_filename)
            target_stat = os.stat(target_filename)
        except WindowsError:
            continue

        delta = 0
        while source_stat.st_mtime < target_stat.st_mtime:
            diff_count  = 1
            #print source_filename, source_stat
            #print target_filename, target_stat
            print 'patching', target_filename
            os.utime(target_filename, (source_stat.st_atime, source_stat.st_mtime-delta))
            target_stat = os.stat(target_filename)
            delta  = 1

print file_count, diff_count
 

это далеко от совершенства, но выполнение команды больше не приводит к тому, что все пытается синхронизироваться. Надеюсь, кто-нибудь сочтет это полезным, другие решения по-прежнему приветствуются.