Копирование жёсткой ссылки

Здравствуйте!
Заканчиваю статью по симлинкам и хардлинкам, в качестве некоторых примеров коснулся их копирования и перемещения. Если с симлинками всё просто и понятно, то с хардлинками столкнулся с некоторым непониманием.

«При перемещении хардлинка в другой каталог (в пределах одного раздела), у него сохраняются все атрибуты и свойства. При простом копировании жёсткие ссылки разыменовываются и превращаются в самостоятельный файл.»
из моей статьи ©
Далее из Вики:
«Для преодоления этого ограничения в UNIX-подобных системах используется конвейер из команд find и cpio:

(в каталоге-источнике)

find -depth -print0 | cpio -p -v -d --null <каталог назначения>

(Ключ -depth заставляет find выводить имена каталогов после их содержимого, благодаря чему команда cpio сможет последовательно воссоздать дерево файлов. Ключ -print0 сохраняет пробелы в именах файлов, меняя разделитель строк на символ NULL (код 0x0). Ключи cpio: -p — режим конвейера, -d — создание каталогов, -v — отображение хода работы, --null — указывает на то, что разделителем строк выступает нулевой символ.)»

Но моя консоль ругается, а я не понимаю почему (ну не силён я в bash командах):
[algri@localhost ~]$ find -depth -print0 | cpio -p -v -d --null оригинал.txt /home/algri/tmp
cpio: Слишком много аргументо
Try 'cpio --help' or 'cpio --usage' for more information.


помогите разобраться, интернет по этому поводу примеров не имеет (по копированию хардлинков), во всяком случае я искал и не нашёл

0

Сообщение от algri14 НЕТ, не сохраняет

Выше я привел листинг. СОХРАНЯЕТ!
Цифра 3 после прав ни о чем не говорит?

0

Сообщение от Eddy_Em cp -aR 1 2

это что такое, откуда и куда, поэтому ничего мне не говорит

0

С перемещением хардлинка хорошо справляется утилита "mv"
[algri@localhost ~]$ mv хардлинк.txt /home/algri/Документы/

"mv" сохраняет все свойства хардлинка и не создаётся новый файл (с новым inode)

0

Сообщение от algri14 Но моя консоль ругается, а я не понимаю почему (ну не силён я в bash командах):

там в команде лишний аргумент - оригинал.txt.

Как правильно сказали, файл-источник и файл-хардлинк по сути одно и то же. У каждого набора данных (файла в ФС) есть как минимум один хардлинк. С точки зрения пользователя данные перестают существовать (становятся недоступными) после удаления последнего хардлинка.

Здесь уже дали правильную команду cp -a как способ скопировать данные и сохранить атрибуты. Думаю, что комбинация find | cpio - просто устаревший способ, который доступен с помощью cp -a. Проверять гипотезу мне немножко лень. Можете проверить и, если это так, включить в статью как курьез или напоминание, что любую информацию надо проверять.

0

Сообщение от siberian-man там в команде лишний аргумент - оригинал.txt.

1) тогда как дать указание на "какой файл скопировать" в указанное место?

Сообщение от siberian-man Здесь уже дали правильную команду cp -a как способ скопировать данные и сохранить атрибуты.

2) как я уже проверил и написал выше (на 1-й стр.), опция "-а" не сохраняет атрибуты хардлинка, а создаёт просто новый файл (inode у них разные),
только опция "-l" сохраняет хардлинк

Сообщение от siberian-man find | cpio - просто устаревший способ,

Возможно, ведь и у rsync -H написано в man'е:
-H, --hard-links — сохранять жесткие ссылки

а по факту создаёт новый файл

0

Сообщение от algri14 тогда как дать указание на "какой файл скопировать" в указанное место?

Никак. Это команда копирует файл с таким же именем в другой каталог.

Сообщение от algri14 не сохраняет атрибуты хардлинка, а создаёт просто новый файл (inode у них разные)

хардлинк и атрибуты это разные понятия.

Хардлинк это запись в ФС (честно не помню в какой таблице). А атрибут - это метаданные (права доступа, временные метки), они хранятся в другой таблице.

0

Сообщение от siberian-man Хардлинк это запись в ФС (честно не помню в какой таблице). А атрибут - это метаданные (права доступа, временные метки), они хранятся в другой таблице.

ОПИСАНИЕ
Для каждого файла существует инода (inode), содержащая метаданные файла. Приложение может получить эти метаданные с помощью stat(2) (и подобных вызовов), который возвращает
структуру stat, и statx(2), который возвращает структуру statx.
...... и так далее..................из man inode

я имел ввиду именно inode и копирование хардлинка, со всеми его свойствами хардлинка

0

Мда... Кстати кое в чем я был не прав. Спасибо, что поправили. Инода это и есть метаданные.

Так вот инода это запись в ФС: там есть что-то вкусное, оно такое-то и такое-то, принадлежат тому-то. А имя файл это запись в ФС, которая говорит, вот это имя укажет на ту иноду. Другое имя файла может указать на эту же иноду. Тогда у некоторых данных будет несколько ссылок в пределах одной ФС. Имя файла и инода это связанные штуки, но из разных списков.

Ну создайте файл и посмотрите на его иноду.
Потом сделайте на него хардлинк и посмотрите на иноды этих двух файлов.
Удалите первый файл и посмотрите на иноду оставшегося файла. Вы увидите одно и тоже значение.

cp, cpio копируют содержимое файла, значит в ФС создается копия данных, и создается новая запись - вкусняшки, масса столько, жбу столько, у кого брать. Инода - другая, новая. Инода это номер записи, стикер на мониторе. У этих команд есть ключи для копирования данных из иноды (масса, жбу, у кого взять и проч.)

mv - не трогает данные (утверждаю только в рамках данной темы, то есть в пределах одной ФС), только переклеивает стикер с одного места на другое.

0

siberian-man, я не стал Вас цитировать, но всё что Вы сказали, — я это знаю, мне просто нужно для статьи «Симлинки-Хардлинки», пример как скопировать хардлинк и чтобы он им остался (похоже Вы не читали всю тему)
Пару примеров уже нашёл, это "cp" и всё та же "ln", было заманчиво предложить чайникам ещё и "rsync", в придачу с Grsync (GUI), но оказалось:
из Вики Archlinux https://wiki.archlinux.org/title/Rsync_(Русский)

Примечание Использование rsync вместо cp/mv эффективно между различными файловыми системами, но не для копирования или перемещения файлов внутри одной файловой системы. Смотрите [1]

К тому же я вообще не пользовался "rsync", а в ней много нюансов, которыми не хочу пока забивать голову, к тому же утилита развивается (если пройти по ссылке)

зы: на opennet.ru есть man rsync => RU , но похоже немного устаревший (или мне показалось)

0

algri14, похоже, что вы вообще не понимаете, чем хардлинк от симлинка отличается!
Объясняю на пальцах: симлинк - это файл, в котором содержится специальная метка "симлинк", а содержание его - путь к файлу, на который симлинк ссылается. Т.к. это - особенный файл (как и директория), то в стандартных сисвызовах есть особые отметки, как его трактовать: как "собственно файл" (т.е. симлинк, чтобы прочитать путь) или как "симлинк" (т.е. следовать далее и работать уже с файлом, на который он ссылается).
В отличие от симлинков, хардлинк - это ОБЫЧНЫЙ файл! Просто у него нет своих "собственных" блоков. Он их разделяет с другими хардлинками. Кстати, в ранних линуксах руту можно было создавать хардлинки на директории, но потом это решили забанить ради спокойствия.
В общем, для системы хардлинк ничем от симлинка не отличается, поэтому "особенной обработки" он удосужится лишь в том случае, если мы при помощи cp/rsync или еще чего-либо копируем целую директорию с указанием флага "archive" или подобного. Тогда В СЛУЧАЕ, если внутри копируемых файлов найдутся несколько хардлинков, в копии они тоже будут хардлинками (т.е. грубо говоря, скопируется один файл, а остальные на него залинкуются). Но если там будут хардлинки, ССЫЛАЮЩИЕСЯ ВЫШЕ, то они будут рассмотрены как обычные файлы!
Ну неужели нельзя это понять?

И, уж тем более, невозможно "скопировать хардлинк"! Просто потому, что он будет рассмотрен как обычный файл. И если есть желание именно хардлинк на него сделать, то и нужно либо указать соответствующий ключ (не копировать, а создавать хардлинки), либо при помощи команды ln сделать новый хардлинк.

0

Сообщение от Eddy_Em В общем, для системы хардлинк ничем от симлинка не отличается, поэтому "особенной обработки" он удосужится лишь в том случае, если мы при помощи cp/rsync или еще чего-либо копируем целую директорию с указанием флага "archive" или подобного. Тогда В СЛУЧАЕ, если внутри копируемых файлов найдутся несколько хардлинков, в копии они тоже будут хардлинками (т.е. грубо говоря, скопируется один файл, а остальные на него залинкуются). Но если там будут хардлинки, ССЫЛАЮЩИЕСЯ ВЫШЕ, то они будут рассмотрены как обычные файлы!

Это похоже на:
«Имманул Кант доказал, что все пять доказательств бытия Божия, известные человечеству, несостоятельны. А затем, словно в насмешку над самим собой, создал собственное, шестое доказательство».

Сообщение от Eddy_Em И, уж тем более, невозможно "скопировать хардлинк"!

с этого места поподробнее,
[algri@localhost ~]$ cp -l хардлинк.txt /home/algri/Документы/ копирует хардлинк, и сохраняет его свойства
[algri@localhost ~]$ cp -a хардлинк.txt /home/algri/Документы/ копирует хардлинк, но НЕ сохраняет его свойства (это уже новый файл)

Сообщение от Eddy_Em Ну неужели нельзя это понять?

не-а, не могу понять, почему
[algri@localhost ~]$ rsync -H хардлинк.txt /home/algri/Документы/ копирует хардлинк, но НЕ сохраняет его свойства (это уже новый файл), хотя в мане написано
-H, --hard-links - сохранять жесткие ссылки

Сообщение от Eddy_Em rsync надо натравливать на директорию, тогда те хардлинки, что там были, ими и останутся. А один файл - это один файл.

а это как, — "натравливать"
зы: я знаю что такое симлмнк и хадлинк, и чем они отличаются, чем схожи,
и ещё, Вы ведёте беседу какими-то урывками, потом опять возвращаетесь в начало, уж если начали объяснять, то доведите нить объяснения до конца
Статью о симлинках/хардлинках я уже написал, она предназначается в основном для новичков. Лезть глубоко в изучение других утилит у меня не было такого желания, но для примера пришлось коснуться, а там "чёрное кажется белым и наоборот", и маны не помогают, а путают.

0

Нельзя писать статью, не разобравшись самому.

0

peter_irich, _sg2, Eddy_Em, siberian-man, приглашаю в блог почитать мою статью, — «Символические и жёсткие ссылки в Linux.»
Не изучать, ибо вы все и так опытные люди, а указать на возможные ошибки.

0

1. "Ссылка в Linux — это дополнительная запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link), либо содержать путь к «файлу-ИСТОЧНИКУ», тогда это «символьная ссылка» (symbolic link)."
Я бы не стал запись о файле в каталоге характеризовать как "дополнительная запись". Запись она запись и есть. Вообще в такой формулировке все записи о файлах - жёсткие ссылки. Сами на себя так сказать Поле в структуре inode так и называется - core.nlinkv2 и в начале жизни любого файла оно равно 1 (сами каталоги начинаю жить с 2).
2. "Информация на жёстком диске содержится в виде байтов и блоков, на них и ссылаются индексные дескрипторы (inode). "
inode ссылаются на экстенты посредством поля core.u3, а не на байты и блоки.

Хотя я для xfs начал приводить поля, привязываясь к конкретному типу ФС. В ext4 структура и её поля несколько другие, но смысл сохраняется.

Вообще
"Удаление «файла-ИСТОЧНИКА» не приведёт к удалению «ИНФОРМАЦИИ» с диска, если у него есть жёсткие ссылки, до тех пор пока счётчик ссылок на inode не будет равен 0, т.е. пока не удалятся все «ХАРДЛИНКИ» и «файл-ИСТОЧНИК».
Например, если вы удалите файл /home/user/файл-ИСТОЧНИК, но у него остался файл /home/user/Документы/файл-ХАРДЛИНК, то «ИНФОРМАЦИЯ» с жёсткого диска удалена НЕ будет, до тех пор, пока существует «файл-ХАРДЛИНК». "
читается с большим трудом, т.к. лично я не понимаю откуда в мире "жёстких ссылок" берутся источники и хардлинки. Все записи-то в каталогах равноправны.

Ну и глобально без понятия inode вообще новичок фиг что поймёт.

Пробежал бегло и честно, не понравилось, как-то сумбурно, повествование скачет туда-сюда. Сугубо личное мнение.

0

_sg2, спасибо за прочтение и оценку, — с точки зрения далеко продвинутого пользователя. А для новичка (который уже не чайник), Ваша фраза, — «inode ссылаются на экстенты посредством поля core.u3,» — звучит как описание свойств "тяжело заряженного векторного базона"
Я старался давать пояснения на понятном для чайников языке, добавлю что в манах частенько скупятся на единственное слово и новички уже не могут понять.
Например, лет 7 назад, в man’е и в стаье мне попалась фраза, про «файловые системы» и я как чайник неправильно её истолковал, а потом долго не мог понять действие утилиты, пока в другой статье, другой автор дал другой вариант, про «другой раздел жёсткого диска», тогда у меня картинка и сложилась правильно.
Второй пример, из man ln:

ln [ОПЦИЯ]... [-T] ЦЕЛЬ ИМЯ_ССЫЛКИ
ln [ОПЦИЯ]... ЦЕЛЬ
ln [ОПЦИЯ]... ЦЕЛЬ... КАТАЛОГ
ln [ОПЦИЯ]... -t КАТАЛОГ ЦЕЛЬ…

Вот эти 4 строчки мне мозг сломали и вывернули шиворот навыворот (лет 10 назад, когда был совсем чайником).
ЦЕЛЬ, — какая цель, куда "прицель", и только «xxblx» мне всё по местам расставил. Мышление у новичков и опытных пользователей очень разное, ну как в детской сказке про букву «Я», когда девочка произносила «тыблоко», вместо «яблоко».

Если в ман подставить "ИСТОЧНИК" (вместо ЦЕЛЬ), то будет понятно сразу всем чайникам. Хотя по логике ведь хардлинк делается на файл-ЦЕЛЬ, именно так думал автор мана, давая такое описание, совершенно не зная про «тыблоко» чайников.

0

Как я понял из русского "man cp", опция '-l' создаёт hardlink - не значит ли это, что при попытке так скопировать hardlink появится hardlink на hardlink? Хотя это всё равно будет hardlink на исходный файл.

0

Сообщение от peter_irich hardlink на hardlink

Не бывает такого, курите маны дальше.

0

Сообщение от peter_irich Как я понял из русского "man cp", опция '-l' создаёт hardlink - не значит ли это, что при попытке так скопировать hardlink появится hardlink на hardlink? Хотя это всё равно будет hardlink на исходный файл.

Получается что именно так, хардлинк на хардлинк в итоге inode у них один и тот же и счётчик ссылок "+1"
-l, --link - создавать жёсткие ссылки на файлы вместо копирования

Сообщение от Eddy_Em Не бывает такого, курите маны дальше.

а Вы нам докажите, или слабо

0

algri14, тут дело какое. Я лично не сторонник "это же новичок, надо ему разжевать заменяя аналогиями", т.к. это ему сразу в голову вбивается не верная терминология. Пример с разделами и ФС - это очень хороший пример. Если отбросить дополнительные абстракции типа lvm, то ну никак нельзя путать раздел и ФС. Мы работаем здесь с файловыми системами, причём тут разделы? С экстентами ещё ладно, но и то, я бы написал правильно, но просто потом оговорился, что а в этих экстентах ужо и хранятся биты и байты нашего файла, пусть так.

Моё личное мнение и даже убеждение - терминология должна быть сразу правильная. Её можно объяснять через аналогии (но не подменять!), но она должна сразу быть правильной.

0

Сообщение от _sg2 Пример с разделами и ФС - это очень хороший пример. Если отбросить дополнительные абстракции типа lvm, то ну никак нельзя путать раздел и ФС. Мы работаем здесь с файловыми системами, причём тут разделы?

С термином «файловая система» большая путаница;
то ли это Ext, XFS, JFS, Btrfs, NTFS, FAT и др.
то ли это структура и иеархия
Ну вот смотрите, на жёстком диске есть два раздела, это ДВЕ файловые системы, и там, и там EXT4, но хардлинк из одного раздела на другой не сделать, — "где логика Зин" , ну никак без "раздела" не обошлось.

0