Изпечатай

[bazu]

Здравейте, близо година отсъствие имам при вас, но успях да се запиша на курса LFS101x Introduction to Linux и за домашно си имам да направя hard и soft link и знам как да ги направя, но мамка му не знам каква е разликата между тях. Благодаря.

[abozhilov]

Файловоте във файловата система сочат към определено място от физическото устройство. Когато го отваряш този файл, файловата система знае точно къде се намира на диска този файл и точно къде свършва.

Когато правиш хард линк към файл А, то създаваш файл с ново име B, който сочи към абсолютно същото място на физическото устройство към, което сочи и файл А.
Това е много различно от копирането на файл, защото когато копираш файл, то копираш съдържанието от физическото устройство, на ново място и новия файл сочи към друго място.
Хард линкове може да правиш само към файлове, които се намират на същата файлова система. Демек ако тръгнеш да правиш хард линк към файл, който се намира на друг партишън, не е възможно. Също обикновено не можеш да правиш хард линкове към директории.

Симлинкът от своя страна е файл, който сочи към друг файл на ниво файлова система. Тоест ако направиш симлинк A към файл B, то когато достъпваш A файловата система следва пойнтъра и достъпва B. 

[laskov]

Ето един пример от практиката за твърди връзки: Пощенски IMAP сървър. Има структура от директории за всеки акаунт с директории за всяка пощенска папка с писма. Всяко писмо е отделен файл в дадена директория. Ако едно и също писмо е пратено до няколко души, всички получатели имат в папката си Входящи твърда връзка към един и същ файл. Във всяка от директориите обаче, файлът има различно име. Ако изпращачът е с акаунт на същия сървър, той има твърда връзка към същия файл в неговата директория Изпратени.

Файл, към който сочат твърди връзки от няколко места се изтрива, когато се изтрие и последната връзка, сочеща съм него.

За разлика от: Файл, към който сочи мека връзка, може да бъде изтрит, при което връзката ще сочи към несъществуващ файл.

[gat3way]

Най-добре можеш да си представиш нещата ако престанеш да разсъждаваш за файловете като за нещо което има име и съдържанието му се намира в някоя директория.

Т.е за тебе може да изглеждат нещата по този начин, но всъщност на ниво файлова система, операционната система се интересува единствено от един обект, наречен inode. Този inode може да го разглеждаш просто като едно число, което е някакъв индекс в структура от данни описваща съдържанието на обектите - на кои блокове по диска се намират. Всичките обекти в една линукска файлова система са inodes - и директориите и файловете и named pipe-овете и симлинковете.

Директорията е малко по-специфичен случай, защото съдържа списък с други inodes и имена на обекти. Сега както може да си представиш, един и същ inode може да се съдържа в произволен брой директории, всичките те са хардлинкове и като четеш и пишеш в тях всъщност пишеш на едно и също място. Всъщност "линк" е малко подвеждащо, няма оригинал и указател към оригинала, по-скоро го приеми като едно и също нещо достъпно от различни места.

Симлинк-а доста повече отговаря на името си - за файловата система това е отделен inode съответстващ на обект, съдържащ информация накъде сочи симлинка (не под формата на inode номер, а на файлово име, това е важно, защото позволява симлинковете да сочат към обекти в други файлови системи). Та тук вече наистина имаме нещо, което да сочи към друго нещо.

[bazu]

Благодаря много прочетох по два пъти точно което сте ми написали и май го разбрах, още ми е чужда материя и трудно асимилирам нещата.

[HQ]

"...exception to this is Mac OS X v10.5 (Leopard) and newer, which use hard links on directories for the Time Machine backup mechanism only."

[d0ni]

Всъщност hard links са остаряла и сбъркана концепция, която дори не мога да се сетя случай, в който да са полезни. Неслучайно в Plan 9 изобщо отсъстват.

Edit: бях писал soft, вместо hard

[jet]

Ами например да си преместиш /home/ директорията нанякъде

[d0ni]

Ами например да си преместиш /home/ директорията нанякъде

mv?

[gat3way]

Точно с /home директорията няма да стане, защото ще те бие през пръстите като решиш да правиш хардлинк към директория.

Също това за по-бързото местене или безопасното местене което няма да fail-не ако не достига място не е валидно, защото mv прави точно същото ако искаш да местиш голям файл в същата файлова система - създава хардлинк и трие "оригинала", не са толкова прости тия дето са го писали

Но си има някои специфични случаи, където вършат най-добра работа. Примерно когато създаваш chroot среда, там има обикновено има някои основни динамични библиотеки и набор от изпълними файлове, които трябва да съществуват. Съществуват две опции - или ги копираш и така пълниш файловата система с дупликати за всяка отделна chroot среда, или правиш хардлинкове. Симлинковете няма как да сработят. Копирането на файлове също е тъпа история щото някой ден ще искаш да ъпдейтнеш тези библиотеки и ще трябва да копираш новите във всяка отделна среда, докато с хардлинковете това си става "автоматично".

[4096bits]

На практика едно име на файл не е нищо пове4е от линк. Операзионната ( файловата ) система не работи с имената на фаиловете когато ги достъпва, а с inodes. Имената на файловете са като указатели към inode на всеки файл.

ls -i ще свърши работата
inode номера е в първото поле

п.п. мразя я тази фонетична   

[d0ni]

Но си има някои специфични случаи, където вършат най-добра работа. Примерно когато създаваш chroot среда, там има обикновено има някои основни динамични библиотеки и набор от изпълними файлове, които трябва да съществуват. Съществуват две опции - или ги копираш и така пълниш файловата система с дупликати за всяка отделна chroot среда, или правиш хардлинкове. Симлинковете няма как да сработят. Копирането на файлове също е тъпа история щото някой ден ще искаш да ъпдейтнеш тези библиотеки и ще трябва да копираш новите във всяка отделна среда, докато с хардлинковете това си става "автоматично".

Точно в точи случай ми се струва по-добра идея да направиш bind/rbind mount на нужните директории, доста по-лесно е за управление.

[gat3way]

Няма да е по-удобно, по-криво ще е според мен. На chroot-натите среди не им трябва пълния набор библиотеки на системата от lib директориите или пък пълния набор изпълними файлове от bin директорията, но няма как да ограничиш кое да е там и кое да не е там.

[d0ni]

Т.е. според теб е по-лесно да управляваш стотина хард линка, отколкото да направиш 4-5 маунта? При положение, че при ъпдейт на основната система ще имаш нови файлове, ще трявно ръчно да оправяш линковете и така нататък, доста играчка. А това, че ще има излишни файлове не е голяма драма. Може би единствено заради suid-нати binary-та може да е проблем, но пак е по-лесно да имаш директория, в която да имаш копие на минималното дървото, което ти е нужно. По този начин може да свалиш минимални инсталации на различни дистрибуции и да chroot-ваш потребителите ти в която дистрибуция им е кеф.

[gat3way]

Когато ми е трябвало навремето, си имах скрипт дето ги създава, те бяха идентични на практика, не е имало специфични нужди, поне нямам спомени да се е налагало в последствие да им се добавя или маха нещо. Но е по-добър вариант отколкото да им сервирам всички системни библиотеки или всички изпълними файлове, някои от тях са и suid-нати и представляват евентуален риск (да, ОК, може да се монтира с nosuid предполагам). Реално погледнато не виждам предимство да монтирам файлови системи вътре. От секюрити гледна точка иначе, копирането на файлове е може би по-доброто решение иначе, защото успееш ли да модифицираш хардлинкнатата библиотека, това важи за цялата система, но обикновено трябва да си root за да го направиш, а ако си root няма никакъв проблем да излезеш от chroot-натата среда така или иначе. Но отново от секюрити гледна точка, chroot средите не са чак толкова прекрасна идея така или иначе., ясно е че успееш ли да си ескалираш правата до root-ски по какъвто и да било начин, всичко отива по дяволите.