LinuxForum.Fans
Тема

вопрос по хардлинкам

Автор: Cruiser78 8 сообщений 2647 просмотров
#293038

Привет всем!

Вопрос простой. Есть система архивации BackupPC. Её особенность в том, что она создает внутри своих рабочих каталогов массу хардлинков на одинаковые файлы. Чем сильно экономит место на диске. Сейчас у меня задача - остановить работу BackupPC (это просто), перенести её наборы данных на другой компьютер и стартовать BackupPC там. На перенесенных наборах. Я туплю - а как перенести эти наборы, если там унутре и живые файлы и хардлинки на них...

#293042
"Cruiser78" написал:
Я туплю - а как перенести эти наборы, если там унутре и живые файлы и хардлинки на них...

просто tar'ом желательно с --check-links, чтобы не упустить какие-либо внешние ссылки...

#293045

можно немного офтопный вопрос?

суть симлинков я понял.

а где применяются хардлинки и для чего они нужны?

#293056
moshell написал:
можно немного офтопный вопрос?

суть симлинков я понял.

а где применяются хардлинки и для чего они нужны?

Это почти одно и тоже. Только есть нюансы в изготовлении и хранении. А именно - самая суть в том, что файлы в юниксах вообще имен не имеют. Принципиально. Файл однозначно идентифицируется уникальным числом, так называемым iNode (кстати, каталог - тоже файл, только имеющий специальную структуру). И вот к этому iNode, к числу, делается link (запись в каталоге), который содержит уже имя, которое понимает человек, и которое удобно передавать в программы. Полная аналогия с username и его UID. Система работает с числами, а человек - с символами. Итак, обычно имеем один link к файлу. Но ничего не мешает сделать еще один link. В другом месте. И назвать его иначе. А потом - третий. В результате на один файл может указывать несколько link'ов. Вроде, имен много, а файл - всего один, уникальный. То, что я описал - есть суть линков, а именно - хардлинков.
К сожалению, хардлинки возможны только в пределах одной файловой системы (только в пределах файловой системы iNode уникальны). Если мы примонтируем к нашей файловой системе какое либо иное устройство - кто даст гарантию, что iNode файлов в нашей и примонтированной файловой системе не пересекуться? Правильно, никто. Пересекутся обязательно. И тогда накрывается вся уникальность системы линков. На что линк будет показывать? На какой именно iNode? Именно поэтому link'и (хардлинки) живут только в пределах одной файловой системы.
Кстати, команда unlink на какие размышленния наводит?
Но, нам то хочется иметь удобную конфигурацию файловой системы для наших нужд. И была придумана концепция символьных ссылок, симлинков. Симлинки не есть прямая связка записи в каталоге с той или иной iNode файла, а есть отдельный файл специального содержимого, в котором указано, на какой иной файл (по полному имени, а не по его iNode) ссылается эта символьная ссылка. Ну а запись в каталоге указывает на этот симлинковский файл. В результате мы можем иметь ссылки в удобных для нас местах на ресурсы, которые смонтированы черти где.

Как то так.

#293557

спасибо.
впервые с линком столкнулся когда нужно было "ярлык" одной директории на рабочий стол закинуть, а в контекстном меню то нема данной функции как в виндое.

и контрольный:
то есть, можно всегда пользоваться симлинками? они круче чем хард линки, получается так, во всяком случае вывод от прочтения был таким.

#293559
"moshell" написал:
то есть, можно всегда пользоваться симлинками? они круче чем хард линки, получается так, во всяком случае вывод от прочтения был таким.

У них разные области применения, так что «крутизна» зависит от конкретной задачи.

#293568
moshell написал:
спасибо.
впервые с линком столкнулся когда нужно было "ярлык" одной директории на рабочий стол закинуть, а в контекстном меню то нема данной функции как в виндое.

Нет проблем закинуть любое нужное действие в контстное меню того же наутилуса. Если то, что ты делаешь можно описать неким скриптом, то этот скрипт можно подвесить как пользовательский сценарий наутилуса.

#293582
Lupo Alberto написал:

У них разные области применения

вот про это я и спрашивал..

Войдите или зарегистрируйтесь, чтобы ответить.