> > hi > > > > When i mount a new drive,i see a folder > > on it called lost and found. > > What is that for exactly? > > > > Is it something i need to worry about as it is > > empty. > > > > > > Thank You > > Not to worry. This directory captures orphaned file > blocks. It should be empty unless something has > happened to your filesystem (such as an abnormal > termination instead of a graceful shutdown). The > fsck program that checks the disk throws any such > blocks there.
Perhaps more precisely, it puts orphaned files (and directories) in there. To explain why, I've got to get a bit technical, but only a bit. By the way, this description applies specifically to UFS filesystems (ZFS doesn't have lost+found directories, and doesn't need them). But UFS is still widely used, and there are filesystem types on other OSs (and maybe even on Solaris) that behave more or less similarly. Each file is internally known within most types of filesystem by an "i-node" number, which is unique within that particular instance of the filesystem. File and directory names are simply a convenience for us humans, and are used by the system to look up the i-node number, which is then used to look up the i-node itself, which is simply a data structure on disk containing the file's attributes, assigned data blocks, etc. You may ignore this paragraph if you wish. In earlier filesystems, the i-nodes were all stored together on the disk, and the i-node number was used as if it were the index of an array to locate the i-node data describing the file; so the "i" perhaps originally stood for "index". Newer filesystem types are at least a bit more complicated, but some of the original terminology and concepts remain, especially on filesystem types that are more or less derivative of the original Unix filesystem (from the 70's), rather than (like ZFS) new and radically different - and also, because on Unix, certain system calls are specified to provide certain information to an application program calling them, including the i-node number of the file they're referring to. Each i-node typically contains a reference count, since files can appear in more than one place, due to hard links; and directories usually have hard links to themselves and to their parent directories (the "." and ".." entries). The filesystem also has a marker that indicates whether it is consistent. If it isn't, fsck is run to check it and fix it if possible. For any i-node with a nonzero reference count, but no directory entry, fsck creates a directory entry in lost+found. Here's the catch, and aside from the distinction between random data blocks and whole files, the reason I bothered to write this: because this only happens when a directory entry was lost or damaged (usually due to a crash while it was being updated), fsck has no way of knowing what the original name of the file was. So it makes up a name based on the i-node number, since as I previously mentioned, that's unique within the filesystem; that's what will appear within lost+found. Permissions and ownership, being part of the i-node (give or take ACLs) will be preserved, but you may well have to look at each file to try and determine if you recognize it, so that you can move it back where it belongs. As long as lost+found is empty, that's a good thing - it means no files have been lost such that someone ought to figure out where they belong, or check the filesystem against the list of files on the most recent backup. For a filesystem containing only individual data files that are usable without other files also being present, the scope of damage is limited to the file lost. But if the file contains software, or data files used together with other data files, the scope of the damage could be greater. So how much effort you put into restoring a file in lost+found to its proper place (or from backup) depends on what you can determine about it. There's a command called "file" that oddly enough, makes an informed guess as to what a file's contents might be. But there's a freeware version that usually recognizes far more than the default version of "file" (usually in /usr/bin) does. Unfortunately I don't have the latest version of Solaris handy at the moment, so I can't readily tell you where the better version might be. This message posted from opensolaris.org
