I am trying to work out whether some serious filesystem corruption is recoverable or not - however, I am struggling to find a definitive description of what i am seeing in /lost+found anywhere on the web.

Can someone describe the different fields (columns) for me in the following output please?:

This is only part of the output, but I would like to know what columns 3, 4 and 5/6 correspond to if anyone knows? The timestamps are messed up too, but I assume that is because the metadata is too corrupt to read correctly?

The first two items are device files; they don't normally contain any real data. 254,0 is the real time clock and 7,161 is a loop device for mounting files as disks. The third line is a named pipe and contains nothing. It's the lines beginning with a hyphen (for regular file) or d (for directory) that contain bits of actual files. For those files, column 5 should give you the size.

I found this post by someone who sorted out a similar situation.

Thanks Hazel, but that doesn't explain what the actual columns mean - for example, if I paste more output here:

c---r-x--x 1 1528955424 15128849 51, 0 Jan 28 1972 #102152097
b-w--wxr-- 1 859431435 574113852 89, 246 Jan 19 1996 #102213035
c-----x-wt 1 4196655230 773975074 79, 32 Oct 22 1906 #102416927
crwxrwsrwx 1 236869347 249451332 72, 2 Apr 21 2000 #102422493
pr----s-w- 1 1076637474 200007680 0 Jun 19 1987 #102622989
p--------- 1 538644768 1613628404 0 Apr 4 1960 #103035796
sr--r--r-x 1 3127640580 2006123232 0 Mar 10 1981 #103035800
c---r-xrwx 1 773849741 794834329 231, 3 Mar 12 2007 #103035804
b-w-r-xrwx 1 1108943193 596771503 175, 17 May 5 1905 #103194675

You say that '254,0' is a real time clock and '7,161' is a loop device - what about the other files above?

All of these files *should* be compressed backup archives, but I have no idea how to link them to files that existed previously (I have a backup listing from before).
What do the numbers in columns 3 and 4 corresponds to? EOF before and after, or something like that...? Where can I find a list of ALL devices and the corresponding 'code' (i.e. 254,0 for a real time clock)?

I need to know what each column represents before I decide whether it is futile to try and restore these files...

And I forgot to add that that post you added doesn't help at all unfortunately!

Sounds reasonable. I would assume the entire filesystem is junk. You cannot trust that the data is either there or complete even if you do manage to "recover" it. fsck is designed to repair the filesystem to a consistent state, not the data. Sometimes you're lucky, sometimes not.
My standard response when I get an incident that leaves my data in an indeterminate state is to reformat and restore. No ifs, not buts.

1 members found this post helpful.

OK, thanks syg00 - I guessed I would have to rebuild anyway, but I just wanted to find out what all of the different 'columns' in the /lost+found output actually meant...

I have searched, but I cannot find any direct reference to it. This is the main thing I would like to know!?

Any clues/links anyone...?

The columns are the same as any other "ls" command. The results are meaningless because the command is trying to make sense of random bytes - garbage in, garbage out.
T'was ever thus.

OK, I agree that this is probably GIGO; if that is the case though, why bother trying to save anything if you are not able to do anything with it afterwards...!?

And the columns are not the same as any other 'ls' command. Spot the difference :

-rw------- 1 root root 913 Apr 22 01:57 file7mDQP_.dat
-rw------- 1 root root 934 Apr 22 01:57 fileDmf0Ws.dat
-rw-------. 1 root root 1 Mar 30 15:18 logdataLvl

c---r-x--x 1 1528955424 15128849 51, 0 Jan 28 1972 #102152097
b-w--wxr-- 1 859431435 574113852 89, 246 Jan 19 1996 #102213035
c-----x-wt 1 4196655230 773975074 79, 32 Oct 22 1906 #102416927
crwxrwsrwx 1 236869347 249451332 72, 2 Apr 21 2000 #102422493
pr----s-w- 1 1076637474 200007680 0 Jun 19 1987 #102622989
p--------- 1 538644768 1613628404 0 Apr 4 1960 #103035796
sr--r--r-x 1 3127640580 2006123232 0 Mar 10 1981 #103035800
c---r-xrwx 1 773849741 794834329 231, 3 Mar 12 2007 #103035804
b-w-r-xrwx 1 1108943193 596771503 175, 17 May 5 1905 #103194675

What do columns 3, 4, 5 and 6 means above?? Someone must know...

You have to rebuild. The only thing that "lost+found" does is to attach non-deleted but orphaned inodes to some directory-entry somewhere. Pragmatically, there's nothing useful to be done with them.

1 members found this post helpful.

OK, thank you sundialsvcs - we will rebuild! I find it strange that fsck bothers to keep the files if we cannot do anything with them though...!?

And I am still interested in the column descriptions as well. What does it all actually mean?

Yes, they are the same as what ls prints when fed garbage. Columns 3 and 4 are the numeric UID and GID and are printed as numbers because looking up those numeric IDs in /etc/passwd and /etc/group did not find a match. For inodes with a type field that translates as character-special or block-special ("c" or "b" in the first column of the permissions), the major and minor device numbers ("51, 0", "89, 246", etc.) are printed in place of the file size normally shown in column 5. You can see similar (but non-garbage) output by running "ls -l /dev". Those inodes now linked in lost+found contain garbage, and ls is just making the most sense possible of it.

1 members found this post helpful.

Fsck cannot make that determination. That is up to the system administrator.
As you have been told - it means the same thing it means with any ls report.

You can read the man page on ls for that.

Another command that sometimes helps is the "stat" command. Stat will give more detailed names for each field.

The purpose of the files in lost+found are to allow the administrator to decide what do to with the data blocks and inodes associated with the name. You can delete them, rename them, identify any contents and give them back to the original owner, and let the user decide what to do with them.

In the past, I have recovered source files that got lost that way.

1 members found this post helpful.

I think sundialsvcs is being unnecessarily pessimistic. That link that I posted showed how an Ubuntu user actually recovered quite a lot of useful data from those files.

OK, thanks gents (and ladies?)! Looking at the 'ls' man pages does actually give me the information I needed before, so apologies for my earlier sarcasm...

There are so many files in /lost+found that it is just going to be easier to bite the bullet and rebuild anyway. The important files we have backed up, so we can restore those. I just wondered if it would be relatively simple to bring the other files back from the dead, rather than having to rebuild them from scratch?!

It would appear not...

You have to compare the effort to rebuild vs. the effort to identify the files from their content among all the anonymous files in lost+found. Using "grep -r" to locate a file containing a fairly uncommon word would be straightforward. Trying to identify all the files from a missing /usr/lib directory would not. If an entire directory got disconnected and reattached in lost+found complete with its content, that's easy to recover. It's all the individual files that are the problem. And even if you recover a file, you need to have a way to check that its content did not get corrupted along with the filesystem metadata.

Many file-repair utilities do this, including Windows' old chkdsk.exe. The objective is to be sure that there are no "in-use" physical files ("inodes ...") that do not have a directory-entry associated with them somewhere. A dummy directory-entry is built in "lost+found," basically so that the file can be "removed." (If you're curious what the orphaned inode contains, you can look at that now, too.)

But, the bottom line: "if a filesystem is hosed ... it's ... ... ... hosed."

1 members found this post helpful.