UNIX / Linux'ta neden dizinlerle bağlantı kurulmasına izin verilmiyor?


130

Unix / Linux'un dizinlere sert linklere izin vermediğini, ancak yumuşak linklere izin vermediğini ders kitaplarında okudum. Bunun nedeni, devirlerimiz olduğunda ve sert bağlantılar oluşturduğumuzda ve bir süre sonra orijinal dosyayı sildiğimizde, bir çöp değerine işaret edecektir?

Döngüler, sert bağlantılara izin vermemenin arkasındaki tek nedense, neden dizinlere yumuşak bağlantılara izin verilir?


2
Nereye ..işaret etmeli ? Özellikle bu dizindeki sabit linki çıkardıktan sonra, dizinde gösterilen ..? Bir yere işaret etmesi gerekiyor.
Thorbjørn Ravn Andersen

2
..fiziksel olarak herhangi bir sürücüde var olması gerekmez. Yine de mevcut çalışma dizinini takip etmek işletim sisteminin işidir, bu nedenle her bir işlemin 'cwd'sine bağlı bir inode listesini tutmak ve kullanımı görünce buna başvurmak oldukça basit olmalıdır ... Elbette, bu, sembolik düşüncelerin akılda tutulması gerektiği anlamına gelir, ancak zaten sembolik bağlantıları kırmamaya dikkat etmeniz gerekir, ve ek kuralın onları yararsız hale getireceğini düşünmüyorum.
Parthian Shot

Bu açıklamayı beğendim . Özlü ve kolay okunur ve / veya yağsız.
Trevor Boyd Smith

Yanıtlar:


143

Bu sadece kötü bir fikir, çünkü sabit bağlantı ile orijinal isim arasındaki farkı söylemenin bir yolu yok.

Dizinlere sıkı bağlantılar verilmesi, dosya sisteminin yönlendirilmiş asiklik grafik yapısını bozabilir, muhtemelen dizin döngüleri yaratabilir ve dizin alt ağaçlarını sarkar fsckve bu da diğer dosya ağacı yürüyüşçülerinin hata yapmasına neden olur .

İlk önce, bunu anlamak için, inode hakkında konuşalım. Dosya sistemindeki veriler diskteki bloklarda tutulur ve bu bloklar bir inode tarafından toplanır. İnode'u THE dosyası olarak düşünebilirsiniz. İnode dosya isimlerinden yoksundur. Bağlantıların girdiği yer.

Bir bağlantı sadece bir inode için bir işaretçidir. Bir dizin, bağlantıları tutan bir inode'dur. Bir dizindeki her dosya adı sadece bir inode için bir link. Unix'te bir dosyayı açmak da bir bağlantı oluşturur, ancak farklı bir bağlantı türüdür (adlandırılmış bir bağlantı değildir).

Sabit bağlantı, bu inode'a işaret eden yalnızca bir dizin girişidir. Siz ls -l, izinlerden sonraki sayı, adlandırılmış bağlantı sayısıdır. Çoğu normal dosya bir linke sahip olacaktır. Bir dosyaya yeni bir sabit bağlantı oluşturmak, her iki dosya adının da aynı inode'u göstermesini sağlar. Not:

% ls -l test
ls: test: No such file or directory
% touch test
% ls -l test
-rw-r--r--  1 danny  staff  0 Oct 13 17:58 test
% ln test test2
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
% touch test3
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
-rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3
            ^
            ^ this is the link count

Şimdi, açıkça görebileceğiniz gibi sert bir bağlantı yoktur. Sabit bir bağlantı normal bir adla aynıdır. Yukarıdaki örnekte, testya test2, orijinal dosya hangi olup sabit bağlantı hangisi? Sonunda, gerçekten söyleyemezsiniz (zaman damgalarıyla bile) çünkü her iki isim de aynı içeriğe, aynı inode'a işaret eder:

% ls -li test*  
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
14445892 -rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3

Gösterilecek -ibayrak ls, satırın başındaki inode numaralarını gösterir. Nasıl testve test2aynı inode numarasına sahip olduğuna dikkat edin, ancak test3farklı bir numara var.

Şimdi, bunu dizinler için yapmanıza izin verildiyse, dosya sistemindeki farklı noktalardaki iki farklı dizin aynı şeye işaret edebilir. Aslında, bir alt dizin bir döngü yaratarak büyükanne ve büyükbabasına işaret edebilir.

Bu döngü neden endişe verici? Çünkü, hareket halindeyken, döndüğünüzü saptamanın hiçbir yolu yoktur (hareket halindeyken inode numaralarını takip etmeden). duDisk kullanımı hakkında bilgi edinmek için alt dizinlerde yinelenmesi gereken komutu yazdığınızı düşünün . duBir döngüye çarptığında nasıl anlarsınız? Sadece dubu basit işi yapmak için hataya açık ve yapılması gereken çok fazla defter tutma var.

Sembolik bağlantılar tamamen farklı bir canavardır, çünkü birçok dosya dosya sistemi API'sinin otomatik olarak takip etme eğiliminde olduğu özel bir "dosya" tipidir. Bir symlink, varolmayan bir varış noktasına işaret edebilir, çünkü bunlar doğrudan bir inode'a değil, isimle işaret ederler. Bu kavram sabit linklerle anlam ifade etmiyor, çünkü bir "hard link" in varlığı sadece dosyanın var olduğu anlamına geliyor.

Öyleyse neden duzor linklerle değil, sembolik bağlantılar ile kolayca başa çıkabilirsiniz ? Yukarıda, zor linklerin normal dizin girişlerinden ayırt edilemez olduğunu görebildik. Bununla birlikte, sembolik bağlantılar özel, algılanabilir ve atlanabilir özelliktedir!  dusembolik bağlantının sembolik bağlantı olduğunu fark eder ve tamamen atlar!

% ls -l 
total 4
drwxr-xr-x  3 danny  staff  102 Oct 13 18:14 test1/
lrwxr-xr-x  1 danny  staff    5 Oct 13 18:13 test2@ -> test1
% du -ah
242M    ./test1/bigfile
242M    ./test1
4.0K    ./test2
242M    .

7
Allowing hard links to directories would break the directed acyclic graph structure of the filesystem. Sabit bağlantılar kullanan çevrimlerle ilgili sorun hakkında daha fazla bilgi verebilir misiniz? Neden sembolik bağları onu ok
user3539

33
Link () sistem çağrısına döngü algılama ekleyerek ve bir döngü oluşturacaksa bir dizin hard link oluşturmanıza izin vermeyi reddederek Mac’lerde izin vermiş görünüyorlar. Makul bir çözüm gibi görünüyor.
psusi

10
@psusi mkdir -pa / b; nocheckln ca; mv ca / ​​b; - kontrolsüzler, dizin argümanlarını kontrol etmeyen ve sadece bağlantıya geçen ve hiç bir döngü yapılmadığından, 'c' yaratmada hepimiz iyidir. sonra 'c' 'a / b' ye taşınır ve a / b / c -> a / - 'den bir döngü oluşturulur () bağlantısında yeterince iyi değil
Danny Dulai

3
Çevrimler çok kötü. Windows bu sorunu, sabit bağlantı dizinleri olan "kavşaklarda" içerir. Yanlışlıkla tüm profilinize izinler uygularsanız, sonsuz bir döngü oluşturan bir dizi kavşağı ortaya çıkarır. Dizinler arasında yineleme yapmak, yol uzunluğu sınırlamaları durdurulana kadar tekrar eder.
doug65536

4
@WhiteWinterWolf, bu bağlantıya göre, zaman makinesi için özel olarak destek eklediler, ancak yalnızca root bunu yapabiliyor: superuser.com/questions/360926/…
psusi

14

Bağlama noktaları hariç olmak üzere, her dizin tek ve biricik ebeveyni: ...

Bunu yapmanın bir yolu pwdcihazı kontrol etmektir: inode '.' ve '..'. Aynılarsa, dosya sisteminin köküne ulaştınız. Aksi halde, geçerli dizinin adını üst öğede bulun, bir yığına itin ve '../' ile karşılaştırmaya başlayın. '../ ..' ile, sonra '../../.' '../../ ..' ile, vb. Kökten çıktıktan sonra, yığınları bastırıp adları yazdırmaya başlayın. Bu algoritma, her dizinin yalnızca bir ebeveyni olmasına dayanır.

Dizinlerle sıkı bağlantılara izin verildiyse, birden fazla ebeveynden hangisine ..işaret etmeli ? Bu, dizinlere sabit bağlantıların izin verilmemesi için zorunlu bir nedendir.

Dizinlere sembolik bağlantılar bu soruna neden olmaz. Bir program isterse lstat(), yol adının her bir tarafında bir işlev yapabilir ve bir sembolik bağlantıyla karşılaşıldığında tespit edebilir. pwdAlgoritma, bir hedef dizin için gerçek mutlak yol adı dönecektir. Hedef dizine işaret eden bir yerde bir metin (sembolik link) olduğu gerçeği hemen hemen önemsizdir. Böyle bir sembolik bağın varlığı, grafikte bir döngü oluşturmaz.


3
Bundan pek emin değilim. ..Ebeveyn için bir tür sanal hardlink olarak düşünürsek , link hedefinin kendisine sadece bir link daha ekleyebileceği teknik bir sebep yoktur. pwdsadece yolu çözmek için farklı bir algoritma kullanmak zorunda kalacaktı.
Benubird

13

Sabit bağlantı dizinlerini taklit etmek için bağlama montajını kullanabilirsiniz

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
sudo umount /else/dummy_but_existing_directory

7

Bu soru hakkında birkaç nokta daha eklemek istiyorum. Dizinler için sert bağlantılara linux'da, ancak sınırlı bir şekilde izin verilir.

Bunu test etmenin bir yolu, bir dizinin içeriğini listelediğimizde iki özel dizin bulmamızdır "." ve "..". Bildiğimiz gibi "." aynı dizine işaret eder ve ".." üst dizine işaret eder.

Öyleyse, "a" dizini alt öğesi olarak "b" dizini olan ana dizinin bulunduğu bir dizin ağacı oluşturalım.

 a
 `-- b

"A" dizini kodunu not edin. Ve ls -la"a" dizininden yaptığımızda bunu görebiliriz. " Ayrıca dizin aynı inode'a işaret eder.

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a

Ve burada "a" dizininin üç tane sabit bağlantısı olduğunu görebiliriz. Bunun nedeni, 797358 numaralı düğümün "." Adına üç sabit bağlantıya sahip olmasıdır. içinde "a" dizini ve adı ".." içinde "b" dizini ve içinde "a" adı verilen dizin.

$ ls -ali a/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .

$ ls -ali a/b/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 ..

Yani burada hardlinkslerin sadece üst ve alt dizinleriyle bağlantı kurabilecek dizinler için bulunduğunu anlayabiliriz. Ve böylece, çocuğu olmayan bir dizinin sadece 2'si hard link olacak ve bu yüzden "b" dizininin sadece iki adet hard link'i olacak

Dizinlerin serbestçe bağlanmasının engellenmesinin bir nedeni, dosya sisteminden geçen programları birbirine karıştıracak sonsuz referans döngülerinden kaçınmak olacaktır.

Dosya sistemi ağaç olarak organize edildiğinden ve ağaç döngüsel referansa sahip olamadığından, bundan kaçınılmalıdır.


1
İyi örnek. Şüphe temizledi. Böylece bu durumlar sonsuz döngülerden kaçınmak için özel bir şekilde ele alınır. sağ?
G Gill

1
Dizinler için katı bağlantılara izin verme konusunda sınırlı bir yolumuz olduğu için, yani ".." ve "." sonsuz bir döngüye ulaşamayacağız ve bu yüzden olmayacaklarından kaçınmak için özel bir yol gerektirmeyecek :)
Kannan Mohan

6

Aşağıdakilerin hiçbiri, dizinlere olan sert bağlantılara izin verilmemesi için gerçek bir neden değildir; Her sorunun çözülmesi oldukça kolaydır:

  • ağaç yapısındaki döngüler zorlu geçişe neden olur
  • Birden fazla ebeveyn, yani "gerçek" hangisi?
  • dosya sistemi çöp toplama

Gerçek nedeni (@ Thorbjorn Ravn Andersen tarafından ima gibi) ne zaman geliyor silmek dizin tarafından işaret dan, birden anne olan bir dizin ..:

..Şimdi neye işaret etmeli ?

Dizin üst öğesinden silinirse ancak bağlantı sayısı hala büyükse, 0o zaman bir yere işaret eden bir şey olmalıdır. ..Hiçbir şey işaret ederek bırakamazsınız ; pek çok program geçerliyse .., sistemin sadece güncelleme için silinmiş dizine işaret eden ilk şeyi bulana kadar tüm dosya sistemini geçmesi gerekecekti ... Ya bu, ya da dosya sistemi, sabit bir bağlanmış dizine işaret eden tüm dizinlerin bir listesini tutmak zorunda kalacaktır.

Her iki durumda da, bu bir performans ek yükü ve dosya sistemi meta verileri ve / veya kodu için ekstra bir komplikasyon olabilir , bu nedenle tasarımcılar buna izin vermemeye karar verdi.


3
Çözmesi de kolaydır: Çocuğa bir bağlantı eklediğinizde veya kaldırdığınızda güncellediğiniz bir çocuk dizininin ebeveynlerinin bir listesini tutun. Kurallı ebeveyni (çocuğun hedefi) sildiğinizde , listedeki diğer ebeveynlerden birine işaret edecek şekilde ..güncelleyin ...
Ocak'ta 15:15

2
Katılıyorum. Çözülecek roket bilimi değil. Ancak yine de bir performans ek yükü ve dosya sistemi meta verilerinde biraz fazladan yer kaplar ve komplikasyon eklerdi. Ve böylece tasarımcılar basit, hızlı bir yaklaşım için gittiler;
Lqueryvg

1
Sym, “yerleşik semantik ve davranışları ihlal eder” dir. Bu nedenle bazı komutlar, sym bağlantılarının izlenip izlenmediğini kontrol etmek için seçeneklere ihtiyaç duyar (örn. Bul ve cp'de -L). Bir program '..' takip ettiğinde başka bir karışıklık söz konusudur, dolayısıyla bir sym linkini geçtikten sonra çıktıdaki fark pwd ve / bin / pwd'den farklıdır. "Unix cevapları" yoktur; sadece tasarım kararlarını ver. Bu, cevabımda belirttiğim gibi ".." olanın etrafında dönüyor. Maalesef, '..' cevabından bile söz etmiyor, başkalarının oy kullanmaya o kadar yakıştığı.
Lqueryvg

Btw, dirs ile sert bağlantılar lehine olduğumu söylemiyorum. Bir şey değil. Gündelik işimin şimdi olduğundan daha zor olmasını istemiyorum.
Lqueryvg

POSIX'in söylediği şey bu değil, ancak IMO '..' hiçbir zaman bir dosya sistemi kavramı olmamalı, yollarda sözdizimsel olarak çözülmeli, bu a/..her zaman anlamına gelirdi .. URL'ler bu şekilde çalışır, btw. Sunucuya bile isabet etmeden önce '..' çözen tarayıcı. Ve harika çalışıyor.
26b

3

Dizinlerdeki hardlink oluşturma geri alınamaz. Diyelim ki:

/dir1
├──this.txt
├──directory
│  └──subfiles
└──etc

Bağlantı kurdum /dir2.

Yani /dir2şimdi tüm bu dosyaları ve dizinleri de içeriyor

Ya fikrimi değiştirirsem? Sadece yapamam rmdir /dir2(çünkü boş değil)

Ve tekrar tekrar silersem de /dir2... silinir /dir1!

IMHO, bundan kaçınmak için büyük ölçüde yeterli bir neden!

Düzenle :

Yorumlar, dizini çıkartarak kaldırılmasını önerir rm. Ancak rmboş olmayan bir dizinde başarısız olur ve dizinin hardlink olup olmadığına bakılmaksızın bu davranış kalmalıdır. Yani sadece rmbağlantıyı kesmek için yapamazsın . rm"Dizin inode> 1 olan bir sayıma sahipse, sadece dizinin bağlantısını kaldır" demek için yeni bir argüman gerekir .

Sırayla, en az sürpriz olan bir başka ilkeyi kırmak: bu, az önce oluşturduğum bir dizin hardlinkinin çıkarılmasının normal bir dosya hardlinkinin çıkarılması ile aynı olmadığı anlamına gelir ...

Cümlememi tekrar yazacağım: Daha fazla gelişme olmazsa, hardlink oluşturma geri döndürülemez (mevcut bir komut mevcut davranışla uyuşmadığı sürece kaldırmayı kaldıramadığından).

Durumun üstesinden gelmek için daha fazla gelişmeye izin verirsek, tuzakların sayısı ve sistemin nasıl çalıştığını, böyle bir gelişmenin ne anlama geldiğini yeterince bilmiyorsanız , veri kaybı riski IMHO'nun dizinler üzerindeki bağlantıyı kısıtlamak için yeterli bir neden olduğunu gösterir.


Bu bir problem olmamalı. Sizin durumunuzda, dir2'ye hardlink oluşturduğumuzda dir1'deki tüm içeriğe hardlink yapmak zorundayız ve böylece dir2'yi yeniden adlandırır veya silersek sadece inode'a ekstra bir link silinir. Ve bu in1 ile en az bir bağlantı (dir1) içerdiğinden dir1 ve içeriğini etkilememelidir.
Kannan Mohan,

3
Argüman yanlış. Bağlantısını kaldırırsın, rm -rf yapmazsın. Bağlantı sayısı 0'a ulaşırsa, sistem tüm içeriği de silebileceğini bilir.
LtWorf

Bu rmzaten az ya da çok her şeyin altında var (unlink). Bakınız: unix.stackexchange.com/questions/151951/… Bu gerçekten bir sorun değil, hardlinked dosyalarda olduğundan daha fazla. Bağlantının kaldırılması yalnızca adlandırılmış referansı kaldırır ve bağlantı sayısını azaltır. Aslında rmdirboş olmayan dizinleri silmez ilgisiz - bu için bunu yapmazdım dir1 ya. Hardlinks veri kopyaları değildir, aynı gerçek dosyalardır, dolayısıyla dir2 dosyasını "silmek" dir1 için dizin listesini siler. Her zaman bağlantıyı kesmen gerekir.
BryKKan

Sadece normal bir dosya gibi bağlantısını kaldıramazsınız, çünkü rmbir dizinde boş değilse bağlantının bağlantısını kesemezsiniz. Düzenle'ye bakınız.
Pierre-Olivier Vares

1

Bu iyi bir açıklama. "Birden fazla ebeveynden hangisi .. işaret etmeli?" çözümlerden biri, bir işlemin tam wd yolunu, inode ya da string olarak sürdürmesi olacaktır. İsimler değiştirilebildiği için inodes daha sağlam olurdu. En azından eski günlerde, bir dosya açıldığında artmış, kapatıldığında azalmış her açık dosya için bir çekirdek inode vardı. Sıfıra ulaştığında ve işaret ettiği depo serbest bırakılır. Dosya artık kimse tarafından açılmadığında, (Çekirdek içi kopya) iptal edilir. Alt dizin başka bir işlemin yolundayken başka bir işlem bir dizini başka bir dizine taşıdıysa, bu yol geçerli olur. Açık bir dosyayı silme şekline benzer, ancak dosyayı dizinden kaldırır,

Hard-link dizinleri Bell Labs UNIX'te, en azından V6 ve V7'de serbestçe izin veriliyordu, Berkeley veya daha sonra bilmiyorum. Bayrak gerekli değil. Döngüler yapabilir misin? Evet, bunu yapma. Bir döngü yaparsanız ne yaptığınız çok açık. Nether, eğer diğer ucunu dökme kafadaki bir kancaya asmak için uygun bir şekilde asılı tutarsanız, uçağınıza doğru dalgalanma sırasını beklerken boynunuzu bağlayan düğümler yapmalısınız.

Bugün onunla yapmayı umduğum ev ile ev arasındaki bağlantıyı zorlamaktı, böylece / home / administ 'nin / home' un bir homeout ile örtülüp örtülüp örtülmeyeceğine bakabilseydim. / administ. Bu, birincil ev dosya sistemimin durumuna bakılmaksızın çalışan bir idari hesaba sahip olmamı sağlıyor. Bu IS linux için bir deney, ama automount'lar ascii dize düzeyinde yapılabilir ki UCB tabanlı SunOS için bir defada öğrenilen düşünüyorum. Aksi halde herhangi bir FS'nin tepesinde bir katman olarak nasıl yapılabileceğini görmek zor.

Bunu başka bir yerde okudum. ve .. artık dizinde de dosyalar değil. Bunların hepsinin iyi sebepleri olduğundan ve bundan zevk aldığımız şeylerin (NTFS'yi kurabilmek gibi) mümkün olduğundan eminim, ancak UNIX’in şıklığının bir kısmı uygulamada. Bu zarafetin, bu kadar sağlam olmasını ve kırk yıl dayanabilmesini sağlayan genelliğin ve satın alınabilirliğin sağlanması gibi avantajlar. Zarif uygulamaları kaybettiğimizde sonunda Windows gibi bir hale gelecektir (Umarım hatalıyım!) Birisi daha sonra zarif prensiplere dayalı yeni bir işletim sistemi yaratacaktır. Düşünmek için bir şey. Belki de yanılıyorum, (açıkçası) mevcut uygulamaya aşina değilim. Bu ise 30 yıllık anlayışın Linux için ne kadar uygulanabilir olduğuna rağmen şaşırtıcı ... çoğu zaman!


Ben yanlış olabilir ama düşünüyorum ki .ve ..çağdaş dosya sistemleri için dosya sisteminde sabit bağlarının, değildir. Ancak dosya sistemi sürücüsü onları sahte. Sabit dosyalama dizinlerini durduran bu dosya sistemidir. Eski dosya sistemleri için mümkün (ancak tehlikeli). Ne yapıyorsan onu yap, bak, mount --bindayrıca mount --make…ve belki konteynerlere de bak .
ctrl-alt-delor

0

Topladığım şeye göre, asıl sebep, diğer dosyalara referans vermek için çalışma dizinlerini kullanan çalışan programları karıştırmadan dizin adlarını değiştirebilmenin faydalı olmasıdır. Diyelim ki Wine'ı çalıştırmak için kullandığınızı ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exeve ~/.winebunun yerine önekin tamamını taşımak istediğinizi varsayalım . Bazı garip bir nedenden dolayı Firefox drive_c/windowsatıfta bulunarak erişiyorsa ../../windows, yeniden adlandırılması ~/.newwineprefix, uygulamaların ..ana dizini izlemesini inode yerine bir metin dizesi olarak takip eder.

Tek bir ana dizinin inode'unu saklamak, her metin yolunu hem bir metin dizisi hem de bir inode dizisi olarak izlemeye çalışmaktan daha basit olmalıdır.

Diğer bir sebep ise, yanlış uygulamaların döngüler oluşturabilmesidir. Davranış uygulamaları, taşınan dizinin inode'unun taşındığı dizinin herhangi bir inode ile aynı olup olmadığını kontrol etmelidir, tıpkı bir dizini kendi içine taşıyamazsınız, ancak bu zorlanmayabilir dosya sistemi düzeyinde.

Yine başka bir neden, dizinleri sabitleyebiliyorsanız, değiştiremeyeceğiniz bir dizini sabitlemekten kaçınmak isteyebilirsiniz. findDiğer kullanıcılar tarafından oluşturulan dosyaları geçici dizinlerden silmek için kullanıldığı için, bir kullanıcı findbaşka bir komut çağırırken, bir kullanıcı bir bağlantı için gerçek bir dizini değiştirdiğinde sorunlara yol açabileceğinden, güvenlikle ilgili kaygıları vardır . Önemli dizinleri bir araya getirebilmek, bir yöneticiyi findetkilememek için ekstra testler eklemeye zorlar. (Tamam, bunu zaten dosyalar için yapamazsınız, bu nedenle geçersiz.)

Diğer bir neden ise, ana direktörün inode'unu depolamanın dosya sisteminin bozulması veya zarar görmesi durumunda fazladan fazlalık sağlayabilmesidir. Bu bağlantıya ..bağlanan tüm üst dizinleri listelemek isteseydiniz , şu anki bağlantı kaldırılırsa farklı, rastgele bir üst öğe kolayca bulunabilirdi; dosya sistemi inode'ları depolar ve kullanır. Programların yolları dizin dizinlerinin bir dizisi (her hardlink'e özgü) olarak ele alması bu durumdan kaçınır, ancak dosya sistemi hasarı durumunda fazlalık elde edemezsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.