Передача уровня 2

Это можно поместить в .bashrc, чтобы изменить имя терминала (имя окна) на последний каталог (или имя файла), в котором вы находитесь (работаете).

случай «$ TERM» в xterm * | rxvt *) PROMPT_COMMAND='echo -ne "\033] 0; $ {PWD # # */}\007 "" ;; *) ;; esac

более подробно описано здесь: ссылка

Прежде всего, относительно части «резюме» вашего вопроса, -партийная просто сообщает принимающей стороне сохранить частично переданные файлы, если отправляющая сторона исчезнет, как если бы они были полностью переданы.

При передаче файлов они временно сохраняются в виде скрытых файлов в целевых папках (например, .TheFileYouAureSending.lRWzDC ) или в специально выбранной папке, если установлен переключатель -партийный-dir . Если передача завершается неуспешно и параметр --partial не установлен, этот скрытый файл останется в целевой папке под этим криптическим именем, но если установлен параметр -partial , файл будет переименован в фактическое имя целевого файла (в данном случае TheFileYouAreSending ), даже если файл не является полным. Это точка, что позже можно завершить передачу, снова запустив rsync с помощью --append или --append-verify .

Таким образом, -частичная не сама возобновляет неудачную или отмененную передачу. Чтобы возобновить его, вам придется использовать один из вышеупомянутых флагов на следующем прогоне. Таким образом, если вы должны убедиться, что цель никогда не будет содержать файлы, которые кажутся хорошими, но на самом деле неполными, вы не должны использовать --парtial . И наоборот, если вы хотите убедиться, что вы никогда не оставляете после себя сбойные сбойные файлы, которые скрыты в целевом каталоге, и вы знаете, что вы сможете завершить передачу позже, -частичный будет вам помочь.

Что касается переключателя --добавить , упомянутого выше, это фактический переключатель «возобновить», и вы можете использовать его независимо от того, используете ли вы также -частичный . На самом деле, при использовании --добавления временные файлы не создаются. Файлы записываются непосредственно в целевые объекты. В этом отношении --добавление дает тот же результат, что и -частное при неудачной передаче, но без создания этих скрытых временных файлов.

Итак, если вы перемещаете большие файлы и хотите, чтобы операция rsync была отменена или прервана с момента остановки rsync , при следующей попытке необходимо использовать переключатель --append или -append-verify .

Так как @ Alex точек ниже, так как версия 3,0,0 rsync теперь имеет новый параметр, --append-verify , который ведет себя как --append до того, как этот параметр существовал. Вы, вероятно, всегда хотите поведение --append-verify , поэтому проверьте свою версию с помощью rsync --версия . Если вы находитесь на компьютере Mac и не используете rsync из home ebrew , вы (по крайней мере, до El Capitan включительно) будете иметь более старую версию и вам нужно будет использовать --append , а не -apend-verify . Почему они не сохранили поведение на --добавление и вместо этого назвали новичка --добавление-без-проверки , это немного озадачивает. Либо путь, --apend на rsync перед версией 3 совпадает с --apend-verify на более новых версиях.

--append-verify не опасен: он всегда считывает и сравнивает данные на обоих концах, а не только предполагает, что они равны. Он делает это, используя контрольные суммы, поэтому это легко в сети, но он требует чтения общего объема данных на обоих концах провода, прежде чем он может фактически возобновить передачу, добавив к цели.

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

Это правильно, и это называется дельта-передачей, но это другая вещь. Для этого необходимо добавить переключатель -c или --checksum . После использования этого переключателя rsync проверяет файлы, существующие на обоих концах провода. Он делает это в кусках, сравнивает контрольные суммы на обоих концах, и если они отличаются, он передает только различные части файла. Но, как указывает ниже @ Jonathan, сравнение выполняется только тогда, когда файлы имеют одинаковый размер на обоих концах - разные размеры заставят rsync загрузить весь файл, перезаписав целевой объект с одинаковым именем.

Это требует некоторого вычисления на обоих концах изначально, но может быть чрезвычайно эффективным для снижения сетевой нагрузки, если, например, вы часто резервируете очень большие файлы фиксированного размера файлы, которые часто содержат незначительные изменения. В качестве примеров можно привести файлы образов виртуальных жестких дисков, используемые в виртуальных машинах или целях iSCSI.

Примечательно, что при использовании --checksum для передачи пакета файлов, которые являются совершенно новыми для целевой системы, rsync будет по-прежнему рассчитывать их контрольные суммы в исходной системе перед их передачей. Почему я не знаю:)

Итак, короче говоря:

Если вы часто используете rsync, чтобы просто «переместить материал из A в B» и хотите, чтобы опция отменила эту операцию и позже возобновила ее, не используйте -checksum , но используйте -append-verify .

Если вы часто используете rsync для резервного копирования данных, использование --append-verify , вероятно, не принесет вам больших результатов, если вы не привыкли отправлять большие файлы, которые постоянно растут в размере, но редко изменяются после написания. В качестве бонусного наконечника при резервном копировании в место хранения, поддерживающий создание снимков файловой системы, например, btrfs или zfs , добавьте --inplace поможет уменьшить размеры снимков, поскольку измененные файлы не создаются заново, а измененные блоки записываются непосредственно поверх старых. Этот переключатель также полезен, если требуется избежать создания копий файлов в целевом устройстве при незначительных изменениях.

При использовании --append-verify rsync будет вести себя так же, как всегда во всех файлах одинакового размера. Если они отличаются изменениями или другими временными метками, целевой объект будет перезаписан источником без дополнительной проверки этих файлов. --checksum сравнит содержимое (контрольные суммы) каждой пары файлов с одинаковыми именем и размером.

ОБНОВЛЕНО 2015-09-01 Изменено для отражения точек, сделанных @ Alex (спасибо!)

ОБНОВЛЕНО 2017-07-14 Изменено для отражения точек, сделанных @ Jonathan (спасибо!)

Точки доступа по существу являются просто реле; когда вы переходите от точки доступа к точке доступа, вы никогда не покидаете сеть, поэтому, если вы не сталкиваетесь с физическим (уровень 1) отсутствием обслуживания где-то в середине, вы должны потерять мало или вообще не иметь данных во время процесса. Это потому, что нет повторного согласования уровня 3; последовательные точки доступа обычно находятся на различных каналах , и аппаратные средства мгновенно переключаются на них. Сетевая подсистема ОС вообще ничего не должна делать (драйвер устройства может быть, я не знаю).

IP-пакеты (включая ping) являются атомарными, что означает, что они доставляются или не доставляются. Вы не можете получить половину пакета; вы можете получить поврежденный пакет, но он будет удален = = нет пакета.

Пакеты могут быть потеряны или иным образом не достичь места назначения.

Если вы быстро перемещениями из сети в сеть , то при отключении от первой сети все пакеты, адресованные вам, будут передаваться маршрутизатором, что означает, что отправитель будет уведомлен через ICMP о том, что вас там нет. Пакеты ping состоят из пар; вы посылаете один, вы получаете один ответ. Фактическая передача данных не подобна; если вы являетесь отправителем, вы можете отправить довольно много пакетов перед ожиданием ответа. Для трафика TCP количество определяется в окне перегрузки ; система не будет посылать больше, пока не получит некоторое подтверждение.

Однако при правильном отключении все TCP-соединения должны быть правильно закрыты. Будут ли они быстро перезаключены при повторном подключении, зависит от ответственного за них программного обеспечения пользователя. Если вы отключитесь, например, при отключении кабеля, другая сторона получит уведомление ICMP от сетевого маршрутизатора, когда он попытается отправить что-либо, и ваше пользовательское приложение, вероятно, получит его от ОС, когда сделает то же самое.