Возврат каретки и потоки битов Перевода строки в двоичном файле во время TFTP загружают в режиме ASCII

С mount --bind, дерево каталогов существует в два (или больше) места в иерархии каталогов. Это может вызвать много проблем. Резервные копии и другие копии файла выберут все копии. Становится трудным указать, что Вы хотите скопировать файловую систему: Вы закончите тем, что копировали связывание - смонтированные файлы дважды. Поиски с find, grep -r, locate, и т.д., пересечет все копии, и так далее.

Вы не получите “увеличенной функциональности, и совместимость” со связывают, монтируется. Они похожи на любой другой каталог, который большую часть времени не является желательным поведением. Например, Samba выставляет символьные ссылки как каталоги по умолчанию; нет, ничто для получения с использованием связывания не монтируется. С другой стороны, свяжите монтирование, может быть полезным для представления иерархий каталогов по NFS.

У Вас не будет проблем производительности с, связывают, монтируется. То, что Вы будете иметь, является головными болями администрирования. Свяжите монтируется, имеют их использование, такое как создание дерева каталогов, доступного от chroot или представления каталога, скрытого точкой монтирования (это - обычно переходное использование, в то время как структура каталогов реконструируется). Не используйте их, если у Вас нет потребности.

Только корень может управлять, связывают, монтируется. Они не могут быть перемещены обычными средствами; они блокируют свое местоположение и каталоги предка.

Вообще говоря, если Вы передаете символьную ссылку на команду, действия команды на самой ссылке, если она воздействует на файлы, и на цель ссылки, если она воздействует на содержание файла. Это идет для каталогов также. Это обычно - правильная вещь. Некоторые команды имеют опции рассматривать символьные ссылки по-другому, например ls -L, cp -d, rsync -l. Независимо от того, что Вы пытаетесь сделать, намного более вероятно, что символьные ссылки являются правильным инструментом, чем связывают, монтирует быть правильным инструментом.

1
14.08.2013, 02:09
1 ответ

TFTP использует подобные механизмы в качестве telnet для передачи ASCII. Это выполняет набором правил до конца в спецификации NVT. Таким образом, эффективно маркеры конца строки завершаются с <cr><lf>, и если Вы хотите отправить фактическое <cr> затем это переводится в <cr><nul>.

hexdumping файл я создал:

00000000  0d 54 65 73 74 69 6e 67  33 0d 0a                 |.Testing3..|

Однако на передаче по tftp (полученный от a tcpdump -X):

0x0020:  0d00 5465 7374 696e 6733 0d00 0d0a       ..Testing3....

Отметьте как <cr><lf> последовательность была преобразована в <cr><nul><cr><lf>.

Когда я разность результаты локального и удаленного файла, я заканчиваю с тем же файлом. Это будет то, потому что <cr><nul> последовательность будет возвращена назад к <cr> и локальный формат (под Unix) для новой строки <lf> и так <cr><lf> превращен <lf> и исходный файл, как передано получен. Я не так уверен в том, как DOS tftp сервер обработал бы <cr><nul><cr><lf> последовательность, у меня есть чувство, что она может исказить вывод, чтобы иметь дополнительное <cr> (<cr><nul> становится <cr> и <cr><lf> становится <cr><lf>), особенно учитывая состояния RFC:

A host which receives netascii mode data must translate the data to its own format. 

Ссылки

TFTP RFC, RFC1350 и спецификация NVT Telnet.

1
27.01.2020, 23:53

Теги

Похожие вопросы