fsck errors and a lot of files in /lost+found

Marti, Robert RJM002 at shsu.edu
Tue Nov 23 13:21:59 UTC 2010



On Nov 23, 2010, at 7:00 AM, "Mertens, Bram" <mertensb at mazdaeur.com> wrote:

>> 
> 
> 
> Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek
> VAT BE 0406.024.281, RPR Mechelen, ING  310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB
> 
> -----Original Message-----
>> From: redhat-list-bounces at redhat.com [mailto:redhat-list-
>> bounces at redhat.com] On Behalf Of Jonathan S Billings
>> Sent: woensdag 17 november 2010 14:18
>> To: redhat-list at redhat.com
>> Subject: Re: fsck errors and a lot of files in /lost+found
>> 
>> On 11/17/2010 07:37 AM, ESGLinux wrote:
>>> Thanks, I can see some files testing first with file command.
>>> 
>>> 
>>> I´m looking for usefull files there but some I don´t know the right
>> place I
>>> have to copy (for example there is a lot of files that are emails but
>> I
>>> don´t know the mailbox where I have to copy)
>>> 
>>> is there any way to know the original location of the files?
>> 
>> No, other from using the context you discover from 'file' or 'less'.
>> 
>> That's why the directory is called lost+found -- fsck doesn't know
>> where
>> they're supposed to go.
> 
> I asked a similar question to this a while ago.  And while I understand the argument about "lost+found" means that fsck doesn't know where to put the files I don't understand why the inode number of the file is known but the name and path aren't.
> 
> Regards
> 
> Bram
> 

fsck looks at the inode, sees that the filename and path are missing/corrupt, but the file is fine. What do you want it to do with those files?  Delete them?

There's nothing that references the filename/path except the inode. If the inode info is broken, there's no way to get that info back. How is that hard to understand?




More information about the redhat-list mailing list