On Nov 23, 2010, at 7:00 AM, "Mertens, Bram" <email@example.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: firstname.lastname@example.org [mailto:redhat-list-
>> email@example.com] On Behalf Of Jonathan S Billings
>> Sent: woensdag 17 november 2010 14:18
>> To: firstname.lastname@example.org
>> 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
>>> 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
>> 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.
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?
redhat-list mailing list
11-23-2010, 01:29 PM
Jonathan S Billings
fsck errors and a lot of files in /lost+found
On 11/23/2010 07:46 AM, Mertens, Bram wrote:
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.
An inode doesn't include file name or path, that's what's defined by the
directory entry for that file. This is why you can have a *hard* link
to the same inode, but the two or more links have different names and/or
When a directory is damaged, you lose that file name and path data.
Fsck creates a directory entry in lost+found to refer to the inodes that
have been orphaned, and names them with their inode name, since there
are no other data available.
Jonathan Billings <email@example.com>
College of Engineering - CAEN - Unix and Linux Support
redhat-list mailing list