Во-первых, если у вас нет запущенного программного обеспечения для этого, оно не будет смонтировано автоматически. Такое поведение полностью обрабатывается из пользовательского пространства, а не в ядре, что довольно важно, поскольку автоматическое монтирование является кошмаром для безопасности (. При тщательно созданном образе файловой системы возможен сбой или, по крайней мере, отказ в обслуживании большинства систем ).
Теперь, что на самом деле происходит, это общая последовательность действий в Linux с использованием стандартной комбинации udev и udisks для запуска автоматического монтирования:
/dev
для устройства. Затем он сканирует устройство и его разделы, чтобы увидеть, какие файловые системы присутствуют и где, и сохраняет эти данные там, где другие программы могут их запрашивать. Теперь, что касается того, как ядро «отслеживает содержимое», это намного сложнее объяснить должным образом. Короче говоря, это не так. Всякий раз, когда вы пытаетесь получить доступ к файлу на устройстве, ядро ищет его в корне файловой системы. Для ускорения этого используется кеш, но на самом деле это не критично ни для чего, кроме производительности.
Локальные операции типа mv four/five /zero/
или cp -r four/five /zero/
не создают /zero/four/
и вряд ли кто-то этого ожидает. Поэтому то, что вы называете «неожиданным», для меня скорее ожидаемо.
tar
хранит предоставленный путь (см. этот вопрос). Воспользуйтесь этим фактом.
cd /one/two/three \
&& tar -cf - four/five | ssh user@bla '
cd /zero && tar -xf -
'
scp
ведет себя здесь так же, как mv
и cp
. Предполагая, что four
содержит другие каталоги, кроме five
, вы можете запустить
ssh user@bla 'mkdir -p /zero/four'
(cd four && scp -r five user@bla:/zero/four/)
, чтобы просто скопировать five
.
mkdir -p
позволяет избежать сообщения об ошибке, если каталог уже существует (cd... )
запускает строку в подоболочке, поэтому вам не нужно cd
из four
впоследствии