Linux ve Unix'teki kayıp + bulunan klasörün amacı nedir?

644

Linux ve Unix işletim sistemlerinin kökünde adında bir klasör var. /lost+found/

Bu ne için? Hangi koşullar altında onunla etkileşime girerim? Bununla nasıl etkileşime girerim?

filesystems directory-structure lost-found

— Wesley
kaynak

Yalnızca ext2 (ve ext3 ve ext4) kullandığına dikkat edin lost+found. Gizlemek istiyorsanız, farklı bir dosya sistemi kullanın veya başka bir yere bağlayın, her şeyi bir alt dizinde tutun ve alt dizini, verileri kullandığınız "gerçek" yere eşleştirin.

— Adam Katz

@Gilles birisini eklemek için yeterince nazikti: en.wikipedia.org/wiki/Fsck#Use

— David Kennedy

lost+foundLinux genişletilmiş dosya sistemine (ext2–4) özgü olduğunu unutmayın . Unices, örneğin FreeBSD tipik olarak bu dizinde dosya sistemlerinde yoktur (UFS, ZFS).

— FUZxxl

Üzgünüz, ama lost+foundneredeyse sonsuza dek BSD sistemlerinde olmuştur. Aslında, sadece kontrol ettim ve kesinlikle 4.3BSD'de vardı ve daha önce hatırlıyor gibiydim. Ve bugün kesinlikle FreeBSD'de.

— Bob Eager

@BobEager Bunu onayladığınız için teşekkür ederiz. Ben de öyle düşünmüştüm ama belki de yanlış hatırladığımı kabul etmeye istekliydim ...

— Pryftan

Yanıtlar:

577

Çalıştırırsanız fsck, dosya sistemi denetimi ve onarımı komutu, dosya sisteminde hiçbir yerde başvuruda bulunmayan veri parçalarını bulabilir. Özellikle, fscktam bir dosya gibi görünen ancak sistemde bir adı bulunmayan verileri bulabilir - buna karşılık gelen dosya adı olmayan bir inode . Bu veri hala yer kullanıyor, ancak hiçbir normal yolla erişilemiyor.

fsckDosya sistemini onarmayı söylerseniz , neredeyse silinen bu dosyaları tekrar dosyalara dönüştürür. Mesele şu ki, dosyanın bir zamanlar bir ismi ve yeri vardı, fakat bu bilgi artık mevcut değil. Bu nedenle fsck, dosyayı lost+found( kaybedildikten ve bulunan özellikten sonra) adlı belirli bir dizine depolar .

Ortaya çıkan lost+founddosyalar, genellikle bağlantısız olan (yani adları silinmiş) ancak sistem aniden durduğunda (çekirdek panik veya elektrik kesintisi olduğunda) hala bazı işlemler tarafından açılmış (bu nedenle veriler henüz silinmedi). Bunların hepsi buysa, bu dosyalar zaten silinmek üzere düzenlenmişse, onları umursamanız gerekmez.

Dosyalar, lost+foundbir yazılım veya donanım hatası nedeniyle dosya sisteminin tutarsız bir durumda olması nedeniyle de görünebilir . Bu durumda, kaybolan dosyaları bulmanızın bir yolu var, ancak sistem onarımı kurtarmayı başardı. Dosyalar yararlı veriler içerebilir veya içermeyebilir ve olsalar bile eksik veya güncel olmayabilirler; hepsi dosya sisteminin zarar görmesine ne kadar bağlı olduğuna bağlı.

Pek çok dosya sisteminde, lost+founddizin biraz özeldir, çünkü fsckdosya depolamak için biraz alan ayırır . (Alan fsckyerinde bırakılan dosya verileri için değil ; oluşturması gereken dizin girişleri içindir fsck.) Yanlışlıkla silerseniz lost+found, yeniden oluşturmayın mkdir, mklost+foundvarsa kullanın .

— Gilles
kaynak

Ayrıca, yanlışlıkla silinen fsck, bir sonraki sefer dosya sistemini temiz bulduğunda (muhtemelen bir sonraki önyükleme olacaktır) yeniden oluşturabilir.

— derobert

Bu klasör zaman zaman kontrol edilip temizlenmesi gereken bir şey midir?

— TheLQ

@TheLQ Yalnızca dosya sisteminiz çok fazla yozlaşmışsa, fsckgerekliydi ve dosya bulmak ve bunları bağlamaktan bahsetti lost+found. Çeşitli dosya sistemlerine sahip 20 yılda, bunu yalnızca bir kez gördüm. Ve bu dergallik öncesi norm oldu.

— Alexios

HDD’nizi biçimlendirirseniz de göründüğünü düşünüyorum (NTFS’den ext4’e geçtim ve göründü)

— puk

@puk lost+foundDizin, sistem kurulumunun bir parçası olarak yapılmış olsun veya olmasın, bir ext4 dosya sistemi oluşturduğunuzda (diğer birçok dosya sisteminde olduğu gibi) oluşturulur. “HDD'nizi biçimlendirin” bunun sadece bir örneği. Ne fsckyapar muhtemelen orada dosyaları eklemektir.

— Gilles

lost+foundRehberi (Bulunan + Kayıp olan) tarafından kullanılan bir yapı olan fsckdosya sistemi (robot cihaz, ama fs için) zarar gördüğü zaman. Dizin bozulması nedeniyle normalde kaybedilecek dosyalar, bu dosya sisteminin lost+founddizininde inode numarasıyla bağlanır . Bunlardan bazıları dizinleri kaybedip, kaybolan dosyaları ve hatta kaybolan aygıtları içerebilir. Her dosya sisteminin kendi lost+founddizini olmalıdır , ancak yalnızca bir dosya sistemine sahip bir sisteme bakıyor olabilirsiniz. Genelde, dizinin boş olduğunu ümit etmelisiniz; Ancak, yolsuzluk varsa, birçok durumda dosyaların fsckburaya yerleştirildikten sonra kurtarılabileceğine şükredin .

— Arcege
kaynak

Ancak geçerli olan nokta: Bunlar yine de çok can sıkıcı olabilir. Örneğin, yönetici olmayan bir kullanıcının hesabından findbir veya daha fazla ext[2|3|4]bölüm (ler) üzerinde bir işlem yapmaya çalışırken , bu tamamen gereksiz "izin verilmeyen" hataları alırsınız . Elbette, bu tür hataların üstesinden gelmenin yolları var - ama bu biraz garip çünkü standart find . -name '*whatever*'hile yapmayacak.

— sözdizimi,

@syntaxerror: Bulmanın sıkıntıları hakkında söylediğinizi duymak güzel : `./lost+found ': İzin reddedildi . Zaman zaman beni de rahatsız ediyor ...

— Johan E

@syntaxerror, bu soruya ulaşmamın sebebi, tam olarak bir keşif işlemi yaptığım ve bir Permission denieduyarı oluşturmaya devam ettiğim içindi . Bu sorunun cevabı göz önüne alındığında lost+found, bunun dosya sisteminin bir parçası olduğunu biliyorum ve bu nedenle oluşturulan uyarıyı güvenli bir şekilde görmezden gelebilirim (ancak uyarının üretmemesini diliyorum).

— Trevor Boyd Smith

@JohanE Bana anlatıyorsun. Ancak, neden asıl nedeni ben bu cevabı bize önermek için çalışıyordu çünkü benim görüş gönderdi oldu "şükretmek" için lost+found. Bu gülünç birkaç kez, (Bir geniş sırıtarak burada oturdu) gerçek olmak için fazla komik hissetti biz yerine bir döküm mümkün olurdu zaman olanlarla rekabet edemez bunun için minnettar oldukları "Begone!" bu sıkıcı lo + fo şemasını yazım.

— sözdizimi

"Linux Dosya Sistemi Hiyerarşisi" den, bölüm / kayıp + bulundu " :

FSSTND'ye genel bakış sırasında daha önce açıklandığı gibi, Linux her zaman uygun bir kapatma sürecinden geçmelidir. Bazen sisteminiz çökebilir veya bir elektrik kesintisi makineyi çökertebilir. Her iki durumda da, bir sonraki önyüklemede fsck kullanarak uzun bir dosya sistemi kontrolü yapılacaktır. Fsck sistemden geçecek ve bulduğu bozuk dosyaları kurtarmaya çalışacaktır. Bu kurtarma işleminin sonucu bu dizinde yer alacaktır. Kurtarılan dosyaların eksiksiz olmaları veya çok anlamlı olmaları muhtemel değildir, ancak her zaman değerli bir şeyin kurtarılması ihtimali vardır. Her bölümün kendi kayıp + bulunan dizini vardır. Dosyaları orada bulursanız, orijinal konumlarına geri getirmeyi deneyin. 'Dosyaya' sembolik bozuk bir bağlantı gibi bir şey bulursanız, dosyayı / dosyaları ilgili RPM'den yeniden yüklemeniz gerekir. dosya sisteminiz o kadar kötü bir şekilde hasar gördü ki, dosyalar tanınmayacak kadar sakatlandı. Aşağıda bir / kayıp + bulunan dizine bir örnek verilmiştir. Gördüğünüz gibi, burada bulunan dosyaların büyük çoğunluğu aslında soketlerdir. Diğer dosyalara gelince, sistem dosyalarına ve kişisel dosyalara zarar verdikleri tespit edildi. Bu dosyalar kurtarılamadı.

— Bhupal
kaynak