Sembolik ve sabit linkler arasındaki fark nedir?


Yanıtlar:


40

Sert ve yumuşak bağlantılar arasındaki farklı semantikler, onları farklı şeyler için uygun kılar.

Sert bağlantılar:

  • Her bir dizin girişi zor bağlantı olduğundan, diğer dizin girişlerinden ayırt edilemez
  • "orijinal", aynı inode'a diğer sabit linkler kesilmeden taşınabilir veya silinebilir
  • sadece aynı dosya sisteminde mümkün
  • izinler "orijinal" ile aynı olmalıdır (izinler dizin girişinde değil inode'da saklanır)
  • dizinlere değil sadece dosyalara yapılabilir

Sembolik linkler (yumuşak linkler)

  • basitçe bu dosyayı başka bir dosya yoluna kaydeder. ( ls -lbir linkin hangi yolu işaret ettiğini gösterecek)
  • orijinal taşınırsa veya silinirse kırılır. (Bazı durumlarda, şu anda hangi dosyanın belirli bir yeri işgal ettiğini gösteren bir bağlantıya işaret etmek aslında istenebilir)
  • farklı bir dosya sistemindeki bir dosyayı gösterebilir
  • bir dizine işaret edebilir
  • bazı dosya sistemi formatlarında, sembolik linkin işaret ettiği dosyadan farklı izinlere sahip olması mümkündür (bu çok nadir)

1
Güzel liste. Sadece eklemek istedim, göreceli bir yolu sembolik bağlantı sembolünü hareket ettirerek de koparabilirsin.
jw013

4
"[E] çok dizin girişi zor link." Bu, daha önce hiç ifade etmediğim mükemmel bir nokta, ancak birinin bağlantılarını sarmaya başlamasına başlayamayacağından endişeleniyorum. Bu durumda olanlar için bir ipucu: ls komutunu çalıştırırken gördüğünüz dosya ve dizinlerin düzeni tam olarak temsil ettiği depolama sistemiyle aynı değil. Sabit bağlantılar, depolama sistemindeki tek bir dosyaya yapılan referanslardır. Bir dosya bir kere saklanır. "İnodes" hakkında okuyun.
Mario

@Mario: yup. Her dizin girişi bir ismi inode'a bağlar. Bir dosya adı silmek için sistem çağrısı bile denir unlink(2). "normal" dosyalar (1 bağlantı sayısı ile) sadece özel bir durumdur. Eğer yardımcı olursa, inode'ları nesne olarak düşünebilir ve isimlendirilmiş işaretçiler olarak adlandırabilirsiniz (inode'un link sayısı referans sayısıdır).
Peter Cordes

1
Sembolik bir bağlantıyı içinde adı olan bir metin dosyası olarak düşünebilirsiniz. Dosyaya özel bir bayrak nedeniyle sembolik bir bağlantı olarak yorumlanır. Bildiğiniz hard link örnekleri ..ve ..
Ned64,

burada dizinlere neden zor bağlantılar yapılamadığını açıklayan başka bir cevap var . Bu cevabı faydalı buluyorum çünkü daha özlü ve okunması kolay.
Trevor Boyd Smith

18

Her iki bağlantı türünün amacı, bir dosyayı aynı anda iki konumda görünmesini sağlamak için bir yol sağlamaktır. Bunun birçok kullanımı var. 10 üzerinden 9 kez sembolik bağlantılar kullanmak istersiniz.

Sembolik bağlantılar veya "sembolik bağlantılar" Windows kısayollarına benzer şekilde çalışır. Bir linkin içeriği, dosyanın / dizinin gerçek konumuna işaretçidir. Gerçek dosyayı silerseniz, sembolik bağlantı "sarkacak" olacak ve çalışmayacaktır. Sembolik bağlantıyı silmek gerçek dosyayı silmez. İstediğiniz kadar tek bir dosyaya (veya hatta diğer işaretlere) kadar birçok sembolünüz olabilir.

Yine de Windows’tan farklı olarak, kabuk veya uygulama düzeyinde değil, dosya sistemi düzeyinde çalışıyorlar, bu yüzden hemen hemen herhangi bir uygulama beklendiği gibi sembolik bağlantıları “izleyecek”. ls -alsembolik bağlantıların "işaret ettiği" yeri görmek için hızlı bir yol olarak kullanılabilir.

Hardlinks daha düşük bir seviyede bile çalışır. Bir hardlink, dosyanın dosya sistemi düzeyinde gerçek, fiziksel bir dizin girişidir. Teknik olarak, bir dizin girişi bir hardlink'tir, dolayısıyla her bir dosya bir yerde bir dizinde en az bir hard linke sahiptir. Hardlinks işaret ettikleri dosyadan ayrı değildir; Bir dosya farklı dizinlerde birden fazla bağlantıya sahipse, bağlantıyı gibi yardımcı programlarla rmsilmek, tüm bağlantıların tümü bitene kadar dosyayı gerçekten silmez.

Dosyaların kasten silinmesini önlemek istemediğiniz veya bölümler veya diğer dosya sistemiyle ilgili şeylerle ilgili garip, düşük seviyeli bir iş yaptığınız durumlar olmadan, hardlinks kullanımının yaygın veya hatta gerekli olduğu durumu düşünemiyorum. EDIT: Bu sorunun diğer cevaplarında harika fikirler var!


Ayrıca, sembolik linkler normal dosyalar gibi izinlere sahiptir, ancak işletim sistemi onlara danışmaz, davranışa karar vermek yerine hedefli dosyaya başvurur. Ve dairesel halka zincirlerini yapmayın. Çok kötü.
LawrenceC

3
Gerçekten çok mu kötü? Ne olacak? Yeniden oluşturabildiğim en büyük heyecan, "Çok fazla sembolik bağlantı seviyesi" hata mesajıdır.
mattdm

1
ls -lBir sembolik bağ ile bağlı olan ne olduğunu görmek için yeterlidir astandları için --allman sayfasına bakınız. Sembolik bağlantılar dosya sisteminde çalışsa bile, sembolik bağları takip etmek yerine dosya olarak kullanmak için alternatif fonksiyonlar vardır.
D4RIO

4
Windows kısayolları aslında sembolik bağlantılardan oldukça farklıdır: hedeflerini takip ederler ve ayrıca normal dosyalardır. (Windows'da ayrıca sembolik bağlantılar vardır, ancak çok fazla kullanılmazlar.) Sembolik bağlantılar tamamen metinseldir, dosyaya her eriştiğinizde hedef metin okunur. Sembolik bağlantı izinlerinin önemli olup olmadığı, işletim sistemine ve dosya sistemine bağlıdır.
Gilles 'SO- kötü olmayı'

AFAIK, bir link link dosyasının içeriği, link link dosyasının boyutuna bakıldığında görülebilecek olan link linkinin gösterdiği yoldur : ln -s /home 1; ls -l 1link link 1'in 5 byte uzunluğunda ln -s /usr/share/ 2; ls -l 2olduğunu gösterirken, 2 nin 11 byte olduğunu gösterir.
daniel kullmann

13

Sabit bağlantılar, disk tabanlı yedekleme mekanizmaları için çok kullanışlıdır, çünkü değişmemiş dosyalar için alan paylaşırken her yedekleme için tam bir dizin ağacına sahip olabilirsiniz ve dosya sistemi referans sayımını takip eder, böylece son başvuru belirli bir sürüm ortadan kalkar, çünkü yedekleme alan nedeniyle boşa çıkarılmıştır / kaldırılmıştır, kullandığı alan otomatik olarak geri kazanılır. Bazı posta istemcileri aynı nedenden dolayı birden fazla klasöre gönderilen iletilerde de kullanır.


5
Belki disk tabanlı sürüm kontrol mekanizmaları? Bir şeyi bir araya getirirseniz, bu bir yedekleme değildir. Orijinal dosya bozulursa, kendisine verilen her bağlantı da bozulur.
D4RIO

1
Apple's Time Machine gibi artımlı yedekleme sistemlerini düşünün. (Bunların felaket kurtarma türü yedekleri olmadığı açık olmalıdır, ancak "ayıklar, bu dosyayı kazayla sildim" yedekleridir.) Artımlı bir yedeklemedeki değişmemiş tüm dosyalar birbirine bağlanır; dosya değiştirildiğinde, bir sonraki adım önceki sürüme bağlanmak yerine onu kopyalar.
geekosaur

Teşekkürler, daha sonra artımlı yedekleme sistemleri bu şekilde sürüm kontrol sistemlerine oldukça benzerdir = D
D4RIO

Ancak artımlı yedekleme mekanizması bir dosyanın "eski" sürümünü nasıl korur? 1) Yedekleme A yaratıldı, dosya F'ye bağlandı. 2) F dosyası değiştirildi; 3) ertesi gün B Yedekleme oluşturuldu ... Görünüşe göre bir şey anlamadım
Dmitry Pashkevich

3

Sabit bağlantılar sadece aynı disk alanlarına yapılan referanslardır, bu nedenle 'neden' başka bir dosya sistemindeki bir şeyi sabitleyemezsiniz.

Symlinks, belki aynı dosya sisteminde, belki de değil, diğer dosyaları (Windows kısayolları gibi) bağlayan dosyalardır.

EDIT: Daha fazlasını açıklayacağım. Var olan her dosya en az 1 sabit bağlantıya sahiptir. Sabit bağlantılar , dosya sisteminin bir inode içeriğine erişmenin yoludur . Bir dosyanın inode numarasını ls -ialabilir ve statbu örnekte aşağıdaki gibi sabit bağlantıların sayısını alabilirsiniz :

$ stat plantilla-disenos.odt 
  File: «plantilla-disenos.odt»
  Size: 12367       Blocks: 32         IO Block: 4096   fichero regular
Device: 803h/2051d  Inode: 319875      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   d4rio)   Gid: ( 1000/   d4rio)
Access: 2011-02-11 21:36:19.000000000 -0300
Modify: 2010-03-02 23:27:28.000000000 -0300
Change: 2010-04-10 17:46:27.000000000 -0300

Bu referans için teşekkürler @geekosaur:

Çekirdeklerin genişletilmesi için çekirdeğin yoldan diziye inode çevirisini (dizin ağacını geçerek) yeniden başlatması gerekir, oysa sert bağlantıların tümü aynı düğmeyi kullanır. (Bunu, geleneksel Unix'te bunu yapan çekirdek işlevinin adından, ad olarak adlandırılır) göreceksiniz.)

ve bu (düzenlendi):

Sabit bağlantılar, Apple'ın Time Machine gibi disk tabanlı artan yedekleme mekanizmaları için çok kullanışlıdır , çünkü değişmemiş dosyalar için alanı paylaşırken her yedekleme için tam bir dizin ağacına sahip olabilirsiniz - ve dosya sistemi referans sayımını izler. Verilen bir sürüme yapılan son referans, alanın sebepleri nedeniyle yedeklemenin süresi dolduğu / kaldırıldığı için ortadan kalktığında, kullandığı alan otomatik olarak geri kazanılır. Bazı posta istemcileri aynı nedenden dolayı birden fazla klasöre gönderilen iletilerde de kullanır.

Şerefe


Performans, sert link kullanmanın faydaları mı? Ya da neden bir sembolik bağlantı yerine bir sabit bağlantı kullandınız?
ripper234

Çekirdeklerin genişletilmesi için çekirdeğin yoldan diziye inode çevirisini (dizin ağacını geçerek) yeniden başlatması gerekir, oysa sert bağlantıların tümü aynı düğmeyi kullanır. (Sık sık nameibunu, geleneksel Unix'te bunu yapan çekirdek işlevinin
adından bahsediyorsunuz

@ ripper234: Hardlinks, yer tasarrufu sağlayan bir çözümdür. Bir sembolik bağlantı oluşturmak için dosya sistemi hakkında bilgi sahibi olmanız gerekmez, ancak sembolik bağlantılar oluşturmadan önce düşünmeniz gerekir, çünkü bir döngü veya uzun bir çözünürlük yolu oluşturabilirsiniz, bu nedenle gibi fonksiyonlar statbaşarısız olur.
D4RIO

@geekosaur: Cevabınızı benim için cevabını çok yararlı olduğu için
ekliyorum

Sorun değil. Aslında sizinkine bir yorum olarak yazmaya başladım, ancak yorumlar çok kısa.
geekosaur

3

Yumuşak bir link başka bir yol adını gösterir. Bu yol, gerçekten var olabilir veya olmayabilir. Sen link linkine erişene kadar yol aranmaz. Yol erişmeye çalıştığınızda yol yoksa, bozuk bir bağlantıya sahip olursunuz.

Sabit bir bağlantıda, birden çok ada sahip bir dosyanız var. Bunlardan birinin “gerçek” dosya olduğunu ve diğerlerinin sadece bunun için bir bağlantı olduğunu söyleyemezsiniz. Hepsi eşittir. Kırık bir bağlantı gibi kırık bir sembolik bağlantı yoktur.

Sabit bağlantılar sadece tek bir dosya sisteminde çalışır. Farklı bir dosya sistemindeki bir dosyaya bağlanmak istiyorsanız (örneğin farklı bir bölüm veya bir ağ paylaşımı), yumuşak bir bağlantı kullanmanız gerekir .

Bağlantılı bir dosyayı sildiğinizde başka bir büyük fark ne olur. Bir çift hardlink dosyadan birini silip aynı isimde yeni bir dosya oluşturursanız, iki ayrı dosyaya sahip olacaksınız (link gitmiş). Bir bağlantının hedefini silip aynı ada sahip yeni bir dosya oluşturursanız, bağlantı yeni dosyayı gösterir.


3

"hard" linkler aynı inode'u paylaşıyor

$ touch foo
$ ln foo foolink # Creates a hard  link
$ ls -li foo foolink
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink

Foo ya da foolink'i düzenlersem sadece bir dosya var ve güncellenecek. Dosya adlarından yalnızca birini kaldırırsam, inode ve veriler devam edecek, aptallar hayatta kalacaktır.

$ rm foo
$ ls -li foo foolink
ls: cannot access foo: No such file or directory
54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink

Aynı şeyi ancak "yumuşak" veya sembolik bir bağlantıyla oluştursaydım, o zaman bir dosya, bir inode ve bir de kendi inode'una işaret eden yeni bir dosya var.

$ touch foo
$ ln -s foo foolink # Create symlink
$ ls -li foo foolink
55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo
55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo

Foo veya foolink'i düzenlersem hala sadece bir dosya var ve güncellenecek.

Yalnızca sembolik bağlantıyı kaldırırsam, inode ve veriler devam eder. Foo'yu kaldırırsam, veriler gider, sembolik bağlantı devam eder fakat var olmayan bir dosyaya işaret eder.

$ rm foo
removed `foo'
$ ls -l foo foolink 
ls: cannot access foo: No such file or directory
lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo

1
Ancak bunun için pratik bir kullanım örneği nedir?
yine beyaz

1
Bir "kısa yol" ile aynı kullanım Bir sistemde bir uygulamanın birden fazla versiyonuna sahip olan bir başka kullanım, bir kutuya yeni bir sürüm kurulmasına, test edilmesine, uygulamanın tam yolla belirlenmesine olanak tanırken, depo gözünde üretime işaret eder. Test tamamlandıktan sonra, yeni sürüme bağlantı değişikliği yapın, sürüme bağımlı kodu olan tüm kullanıcılar için eski sürümü yerinde bırakın. Perl, python, vb. Düşünün
bsd

1
Sabit bağlantılar için pratik kullanım çantası. Şu anda dosya sistemimde / usr / share / zoneinfo içinde çok sayıda hardlinks buldum. Hepsi EST ile aynı olan zaman dilimlerini temsil eden adlandırılmış tüm dosyaları düşünün. Yedekli kopyalara sahip olmadan dosya sistemi alanından tasarruf ediyoruz ve paketler kurulduktan / silinirken sembolik bağlantıların kurulum / silme ek yükü olmadan daha kolay paket yönetimine izin veriyoruz. Biri kaldırılsa bile orijinal veriler korunur. Üzgünüm, daha bilgili bir açıklama için zamanım olmadı.
bsd

1

Sabit bağlantılar, aynı dosya için ek dizin girdileridir. Bunun anlamı

  • Bir dosyaya yapılan tüm sabit bağlantılar aynı dosya sisteminde olmalıdır (çünkü bir dizin girişi farklı bir dosya sistemindeki bir dosyayı gösteremez), ancak aynı dizinde olması gerekmez.
  • Orijinal dizin girişi ile yeni hard link arasında fark yoktur; İşletim sistemi açısından aynı dosyaya sadece iki dizin girişidir. Bir dosya yalnızca tümü silinirse sabit bağlantılar silinirse silinir (ve ayrıca, hala açık olan bir işlem kalmadı).
  • "Orijinali" başka bir dosya sistemine taşımazsanız taşımaz / yeniden adlandırırsanız, diğer sabit bağlantılar etkilenmez; hala aynı dosyaya işaret ediyorlar.
  • Pek çok editör kaydederken yeni içeriği aynı dosyaya yazmaz, ancak aşağıdaki prosedürü uygular:

    1. Bir yeni içerik yaz yeni dosyaya yazın.
    2. Eski dosyayı bir yedekleme adına yeniden adlandırın (veya önceki dosya sürümünün yedeklerini tutmuyorsanız, yalnızca silin).
    3. Yeni yazılan dosyayı önceki dosyanın adıyla yeniden adlandırın.

    Bu şema, aynı dosyaya yapılan diğer herhangi bir sabit bağlantının artık geçerli dosyayı göstermediğini, ancak önceki sürüme işaret edeceği anlamına gelir (editör eski dosyayı sildiğinde bile geçerlidir, çünkü Unix altında bir dosyayı "silme" sadece bağlantısının silinmesi anlamına gelir; yalnızca silinen bağlantı, asıl dosyanın silindiği tek bağlantıysa).

  • Sabit bağlantı doğrudan dosyaya gittiğinden, o dosyanın orijinal konumuna erişiminiz olmasa bile (örneğin, orijinal girişin bulunduğu dizinde herhangi bir izniniz olmadığı için) o dosyaya erişebilirsiniz. . Erişiminizi belirleyen tek haklar, dosyanın kendisinin erişim hakkıdır (dosyayla ilişkilendirilir, bağlantıyla değil; aynı dosya için farklı izinlerle bağlantı kuramazsınız) ve yolun bağlantı için erişim haklarıdır. (temelde, bağlantının bulunduğu dizini ve doğrudan ve dolaylı üst dizinleri çalıştırma hakları) bulunur.

Diğer yandan, sembolik bağlar, başka bir dosyanın yol adını (dosya adı - veya daha doğrusu dizin girişi - potansiyel olarak yolu /bin/shda dahil subdir/foo.bar) saklar . Yol adı göreceli ise, her zaman bağlantının bulunduğu dizine göre yorumlanır.

  • Sembolik bir bağlantı, farklı bir dosya sistemindeki dosyaları (hatta FAT gibi sert veya yumuşak bağlantıları desteklemeyen bir dosya sistemine bile) işaret edebilir.

  • Orijinal dosya silinirse, sembolik link dosya içeriğini korumaz. Aynı dosyaya başka sert bağlantılar olmadığı sürece, dosya içeriği kaybolur. Daha sonra sembolik bağlantı sarkacak şekilde bırakılacaktır (yani, bir dizin girişine karşılık gelmeyen bir yol adına atıfta bulunun). Öte yandan, sembolik bağlantıyı silmek orijinal dosyayı etkilemez, çünkü yalnızca yol adını gösterir.

  • Orijinal dosya taşınır veya yeniden adlandırılırsa, sembolik bağlantı güncellenmez, ancak sarkan solda kalır. Sembolik bağlantıyı taşırsanız, yalnızca göreceli bir yol içeriyorsa kopar ve yol artık yeni konumdan geçerli değildir.

  • Orijinal dosya aynı ada sahip yeni bir dosyayla değiştirilirse (yukarıda açıklanan düzenleyici senaryoda olduğu gibi), bağlantı yeni dosyaya atıfta bulunur.

Sabit bağlantıların çoğu, temel olarak dosya içeriğini iki kez depolamak zorunda kalmadan bir dosyanın kopyasına sahip olmanın bir yoludur. Bu, dosyalar bir daha asla değiştirilmezse işe yarar, aksi halde bağlantıyı yanlışlıkla kesmek kolaydır (yukarıdaki editör senaryosuna bakın). Elbette, istediğiniz davalar var. birkaç yedeklemede olduğu gibi, bağlantının kopmasını : Yeni yedeklemelerde değişen dosyalar için, eski yedeklemelerdeki kopyanın da değişmesini istemezsiniz.

Normalde bir bağlantı istiyorsanız, sembolik bir bağlantı kullanırsınız. Bir örnek, bir dizini başka bir bölüme taşıdığınızda (üzerinde bulunduğu alan dolduğu için), eski konumdan yenisine yumuşak bir bağlantı ayarlayabilirsiniz, böylece eski yerde dizine erişmeye çalışan herhangi bir program bunun yerine yeni yerden eriş. Bu zor linklerle mümkün olmazdı. Ancak taşınan dizindeki sembolik bağlantıların, taşınan dizinden çıkan göreceli yollar içeriyorsa kopabileceğini unutmayın.


1

HARD LINK (Sadece Dosyalar) vs SOFT LINK (Dosyalar veya Dizinler) vs BIND (Dizinler için HARD LINK)

YAZDIRMADAN ÖNCE BU GÖRÜNTÜ İNCELE
(kaynak: freesoftwareservers.com )

Daxelrod'un cevabı soruyu iyi açıklarken, bu davadaki resmin özellikle de inode anlamayan ve Linux'u henüz karmaşık hale getirmeyen yeni başlayanlar için büyük bir fark yarattığını düşündüm.

Bunu düşünün, sürücünüzdeki her şeyi "sildiyseniz", verileri geri yüklemek için yazılım çalıştırabilirsiniz, çünkü 1'ler ve 0'lar hala oradadır, sadece tüm Sabit Bağlantıları sildiniz. Kurtarma Yazılımının amacı, 0 ve 1’leri anlamak için Sabit Bağlantıları yeniden oluşturmaktır.

Tüm bunları mantıklı kılan harika bir "tek gömlek" okudum ve paylaşmak istedim!

Linux'taki tüm dosyalar diskteki 0'lara ve 1'lere "Hard Links" dir. Bir veri oluşturduğunuzda (0 ve 1'ler) işletim sistemi, sabit diskte bu noktaya atıfta bulunmak için Dosya Ağacı'nda bir Sabit Bağlantı oluşturur.

HARD LINK 2 oluşturun ve HARD LINK 1 Orijinal Dosyasını silin :

Başka bir sabit link oluşturabilir ve orijinal dosyayı silebilirsiniz ve yine de yeni oluşturulan sabit linke erişebilirsiniz.

SOFT BAĞLANAN DOSYAYI (HARD LINK 1) silin:

HARD LINK 1'i sildiyseniz, SOFT LINK'in işe yarayacağını düşünüyor musunuz? Hayır, işletim sistemi HARD LINK 1'in mevcut olmadığını geri bildirir.

SOFT LINK'I HARD LINK'a sil:

Tersine, SOFT LINK'ü silerseniz, HARD LINK çalışır mı? Evet. İşletim sistemi bir HARD LINK Dosyasına sahip olduğu sürece , dolgunun silinmediğini bildirir.

- Ayrıca araştırmaya / kaydetmeye değer BIND, iki dizini birbirine bağlamak gibi iki dizini birbirine bağlayabilmenin bir yoludur, ancak işletim sistemi için şeffaftır (işletim sistemleri Symlink'i ne zaman söyleyebileceğini ve bazılarının Symlinks'i izleyebilecekleri ile ilgili kuralları olduğunu söyleyebilir). LS değil, Mount kullanır ve FSTAB üzerinden yapılandırılabilir.

BIND montajı nedir


1
Özellikle ilk mesaj için oldukça iddialı bir çaba. Ne yazık ki, "bağlama" üzerine malzeme eklenmesinin (istenmediği) sadece konuların kafasını karıştırdığına inanıyorum; özellikle de "bağlama" montajını açıklamak için çok çaba sarf etmediniz. Ayrıca, sert ve yumuşak / sembolik bağları çok iyi anlıyorum ve resminizi zar zor anlıyorum. Bir acemi ondan bir şey öğrenirse çok şaşırırdım.
G-Man

Dizinleri işaretleyebilseniz de, dosya sisteminde bir işaret olarak gösterilir, BIND ise, OS'ye şeffaftır. Tıpkı bir dosya gibi görünüyor.
FreeSoftwareServers

1
(1) Aslında Linux en azından bazı sürümlerinde, sen yapabilirsiniz dosyayı monte bağlamak. (2) Bağlama bağları, sabit bağlantılara çok benziyor olsa da, "Bağlama yalnızca zor bağlantılarla aynıdır (bir dizini zor bağlayamazsınız hariç)") sadece yanlıştır.
G-Man

@ G-Man, kabul edildi ve kaldırıldı,
BIND'den

@Free aslında yumuşak link bir dosya ismini gösterir (hard link 1); şemalar, bunu açıkça ortaya koymalıdır.
JB.

0

Sabit bağlantı, bir dosyayı tüm dosyalara, hatta ilk (bir "dosya adı" teknik olarak bir bağlantıdır) silinene kadar diskte tutacaktır. Yumuşak bir link, işaret ettiği dosya değiştirilene kadar "sarkan" bırakılabilir.


0

Bu çok eski bir soru, ancak benden sert bağlantılar kullanmamı gerektiren bir kullanım durumum var.

Ben bir müzisyenim ve bu yüzden Mac'ime bağlı birkaç sabit diskte çok ve çok sayıda ses dosyası var. Terabayt değer. Bunları çoğunlukla sembolik dizin dizinleri ile çok güzel bir şekilde organize ettim; böylece onları içerik yayıncısı, stil / ses ve o sırada nasıl düşündüğüme göre diğer kriterler yoluyla bulabilirim. Maalesef, kullandığım bir program olan Ableton Live, dosya tarayıcısından takma adları veya işaret linklerini göremiyor. Bulduğum tek çözüm, görebilmesini istediğim dizinlerin sıkı linklerini oluşturmak ve sonra her şey harika çalışıyor.

Yani, bu, başkalarına oluşmamış olabilecek zor bağlantıları kullanmanız gerekebileceği başka bir durumdur.


Ableton Live için bir hata raporu hazırlarım. Belki bunu düzeltebilirler.
aventurin

Evet, bu konuyla ilgili olarak yıllardır kabilesinin forumlarında çok fazla şikayet var ... Neden olduğunu anlayamadığım halde bunu ele almak için herhangi bir girişimde bulunmuyor gibi görünüyor.
Jonathan van Clute
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.