rsync копирует файлы из рабочего каталога в дополнение к запрошенным
Все остальные дистрибутивы, которые вы пробовали, имеют более новые ядра, которые 10.04.
Очень вероятно, что ваши проблемы можно проследить до этого.
К счастью, 10.04 имеет Одиночное (11.10) ядро, поддерживаемое и доступное для установки.
Поскольку у вас нет подключения к Интернету, вам нужно будет:
Удалить жесткий диск и подключить его к компьютер, который имеет другой сетевой адаптер, с которым вы можете подключиться к Интернету. Используйте связанный вопрос выше, чтобы установить PPA и последнее ядро. Загрузите пакеты с резервным доступом вручную, перейдите на свой компьютер и установите.Если вы выберете вариант 2 - загрузите пакет изображений, соответствующий вашей архитектуре
i.e. kernel backported и 64bit
, затем установите с помощью синтаксиса:
sudo dpkg -i [foo] .deb где [foo] - имя файла пакета
Вы можете проверить правильность загрузки с этим новым ядром через uname -a
2 ответа
Исходный код был
DRYRUN="-n"
DRYRUN=""
...
rsync "${DRYRUN}" -avushi --stats --progress --log-file="${LOGFILE}"
/media/dataspace/data/webcasts/ "${MOUNT}${DESTDIR}"
Рабочий код
DRYRUN=1 ## for testing rsync without any file transfers
DRYRUN=0 ## for live run
...
if (( ${DRYRUN} ))
then
rsync -n -avushi --stats --progress --log-file="${LOGFILE2}" /media/dataspace"${DESTDIR2}"/ "${MOUNT}${DESTDIR2}"
else
rsync -avushi --stats --progress --log-file="${LOGFILE2}" /media/dataspace"${DESTDIR2}"/ "${MOUNT}${DESTDIR2}"
fi
«Мы встретили врага, а он - мы!» - Уолт Келли (комическая поло Pogo)
Я нашел его! [] D3]
Я не совсем понимаю, что произошло, но, поставив «$ DRYRUN» в командной строке rsync, он сделал первый аргумент rsync «». По-видимому, это интерпретировалось как PWD, а не как ошибка. Таким образом, команда была передачей «» и моим реальным источником для моего реального адресата, потому что rsync принимает несколько источников.
Остается вопрос, почему rsync считает, что «» означает текущий каталог вместо того, чтобы интерпретировать его как синтаксическую ошибку ?
-
1Аргументы файла могут иметь вид user@host:path. Я не знаю, как rsync анализирует это, но это может быть побочным эффектом его анализа вместо того, чтобы просто рассматриваться как путь к локальному файлу (например, cp). На стороне примечания, чтобы избежать ошибок в будущем, вы должны вводить строчные имена переменных, чтобы избежать случайного переопределения специальных переменных оболочки или переменных среды. – geirha 16 March 2012 в 13:47
-
2@geirha В книгах, которые я читал о программировании bash, все сказали использовать верхний регистр для переменных - это было соглашение. Программировавшись на других языках, потребовалось некоторое время, чтобы привыкнуть. Полагаю, кому-то придется посмотреть исходный код rsync, чтобы получить реальный ответ, но я не уверен, что смогу это понять. – Joe 21 March 2012 в 11:02
Ваш случай настолько прост, что вы можете просто удалить кавычки вокруг переменной:
rsync $DRYRUN -avushi --stats --progress --log-file="${LOGFILE2}" /media/dataspace"${DESTDIR2}"/ "${MOUNT}${DESTDIR2}"
Но вам могут понадобиться кавычки в другом случае, например, если параметр - это путь, содержащий пробелы, которые могут быть определены или не определены. Итак, вот более элегантное решение:
linkdest="<OLD_BACKUP_PATH>"
rsync ${linkdest:+--linkdest="$linkdest"} -avushi --stats --progress --log-file="${LOGFILE2}" /media/dataspace"${DESTDIR2}"/ "${MOUNT}${DESTDIR2}"
Если $ linkdest пуст, ничего не будет вставлено. Если $ linkdest не пуст, будет вставлен --linkdest = "$ linkdest" (и он будет оцениваться как команда, а не как строка).
-
1+1 для полезного метода кодирования. Вы правы, что я мог просто удалить цитаты, но только после того, как я понял, что это проблема. То, что я хотел оставить читателям, состоит в том, что если вы случайно предоставили rsync нулевым параметром, как я, это вызывает неожиданное поведение. По-видимому, несколько других команд оболочки Linux делают то же самое. – Joe 24 August 2014 в 03:22