tanya@adds.newyork.NCR.COM (Tanya Katz) (05/18/89)
After fsck reattaches a file to directory lost&found,
it names it with the inode. Is there a nice neat way
of determining what file this was originally?
Usually I use 'file' to learn more about it, then
try to deduce from the type or contents, what it is.
But if it's an object file, I usually search the string
table (if it has one) or the symbol table, to try to
figure out what it is...
Isn't there a more sophistocated method to identify
an object?
Tanya
------------------------------------------------------------------------------
### ###### ###### ##### Tanya Katz (516) 231-5400 x430
# # # # # # #
# # # # # # ##### ncrlnk!adds!tanya
####### # # # # # tanya.katz@adds.newyork.ncr.com
# # ###### ###### #####
Applied Digital Data Systems, Inc. 100 Marcus Blvd., Hauppauge, NY 11788
------------------------------------------------------------------------------tel@cbnewsh.ATT.COM (thomas.e.lowe) (05/19/89)
>After fsck reattaches a file to directory lost&found, >it names it with the inode. Is there a nice neat way >of determining what file this was originally? >Usually I use 'file' to learn more about it, then >try to deduce from the type or contents, what it is. > But if it's an object file, I usually search the string >table (if it has one) or the symbol table, to try to >figure out what it is... >Isn't there a more sophistocated method to identify >an object? > Tanya Unfortunately, No there isn't. The reason is that UNIX(R) keeps all of the information specific to a file in something called an inode. This information includes such items as permissions, creation, modification, and access dates, ownership, groupership(new word), size, and address of data blocks on the disk where that file resides. There are several other things, but none of which is the NAME of the file. The names of the files are kept ONLY in the directory files. Directory files are simply lists of file names and inode numbers, nothing more. Remember that one file can be referenced by more than one name, and even in more than one directory by use of links (the ln command). When fsck has to put an inode in lost+found, it's because it can't find any reference to that inode in any directory on the file system, thus it can't find it's name. I hope this answers the question. Note that this information may be System V specific, but probably applies to most other versions. -- Tom Lowe tel@hound.ATT.COM or att!hound!tel 201-949-0428 AT&T Bell Laboratories, Room 2E-637A Crawfords Corner Road, Holmdel, NJ 07733 (R) UNIX is a registered trademark of AT&T (keep them lawyers happy!!)
chris@mimsy.UUCP (Chris Torek) (05/19/89)
In article <1099@adds.newyork.NCR.COM> tanya@adds.newyork.NCR.COM (Tanya Katz) writes: >After fsck reattaches a file to directory lost&found, >it names it with the inode. Is there a nice neat way >of determining what file this was originally? Which of its up-to-32000 possible names would you prefer? Consider, e.g., vi, which is also known as edit, ex, e, and view. There is never any guaranteed way to turn an inode into a single pathname, because an inode may have anywhere from zero to (some large number that varies with the implementation) names. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
alex@wolf.umbc.edu (Alex Crain) (05/19/89)
In article <1099@adds.newyork.NCR.COM>, tanya@adds.newyork.NCR.COM (Tanya Katz) writes: > But if it's an object file, I usually search the string > table (if it has one) or the symbol table, to try to > figure out what it is... > > Isn't there a more sophistocated method to identify > an object? Try "what <filename>". In my experiance, however, binarys (or anything else) that go to lost+found usually have some trash in them, so their probably no good. Most of the files that I find in lost+found are intermediate files from the compiler, representing changes in the inode table that never got flushed to disk. :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu Univ Md Baltimore County umbc3.umbc.edu!nerwin!alex
jon@jonlab.UUCP (Jon H. LaBadie) (05/21/89)
In article <2060@umbc3.UMBC.EDU>, alex@wolf.umbc.edu (Alex Crain) writes: > > .... Most > of the files that I find in lost+found are intermediate files from the > compiler, representing changes in the inode table that never got flushed to > disk. As the summary says, if the system goes down, even on an orderly shutdown, you may find the working copy of your ksh's history file unconnected and moved to the lost+found. -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon