how to configure lostandfound

I know only this much that there is some thing called LostAndFound in linux which equivalent to RECYCLEBIN in windows. Please if this information is correct kindely any one guide me how to configure it.

When you run e2fsck, you will get some informative output, and some
questions about what damage to repair. Answer `yes' to everything that
refers to `summary information' or to the inodes you've changed. Anything
else I leave up to you, although it's usually a good idea to say `yes' to
all the questions. When e2fsck finishes, you can remount the file system.

Actually, there's an alternative to having e2fsck leave the files in
/lost+found: you can use debugfs to create a link in the file system to the
inode. Use the link command in debugfs after you've modified the inode:

" lost+found " is a holding directory and work space for the Linux
and UNIX systems'
"File System Check" - fsck tool. It actually is NOT like the
"Recycle Bin" in Windows
at all. When a file is removed in Windows, it is placed in the
Recycle Bin. Meaning,
the file is not physically gone - but placed in this temporary bucket
for further processing.

In Linux, every file and directory has a small block of housekeeping
information that details
where the data is physically located on the disk, the file's mode (
aka permissions ), owner
etc. "chmod" purely means "change mode" - change the
permissions. The block of information
is call the interior node - inode. Go to a directory and enter "
ls -li ". The number in the
left most column is the inode for each file and subdirectory.

A fundamental concept in UNIX and Linux is that EVERYTHING is a file,
( a directory is
really just a file of files ), and everything has an inode. The
numeric identifier of the inode
is irrelevant. The system assigns an inode sequentially with each
file or directory creation.

The inode block is cleared out and re-used when a file is remove.
This is why a file ( basically ),
can not be recovered in Linux once removed. All references to data
block locations on the disk
where the data was held are gone. This is why it's mandatory to
create an " rm -i " alias for the
" rm " command for all users - especially root.

cd to the root directory and do an " ls -l ". Notice that size
of lost+found appears quite large
compared to other directories. But if you cd into lost+found it's
empty ( most of the time ) !
lost+found is a work place / recovery area for fsck. I've
talked about inodes. If an indoe
gets corrupted , you can get into real trouble. The physical
location of the data blocks on the
platter are stored in the inode with a bunch of other file
information. Further - a corrupt inodes
situation can avalanche and cause more problems - way beyond the scope
of this email.
fsck is the tool to fix most system problems that relate to inodes.
fsck normally auto runs
at machine bootup. It is also VERY wise to regularly take a system
to single user mode and run
fsck on all partitions. Inode problems can slowly grow and wreck a
system. Though rare - it's
the old " ounce of prevention " rule. fsck should not be run in
multi-user mode.

When inodes get corrupted - it's a very unstable and potential serious
situation. Working on
them needs to be isolated thus a lost+found directory. Do not put
anything into lost+found.
It's only for fsck use. Notice also that EVERY file system needs
a lost+found directory.
The lost+found dir will be under the mount point for every dir.

Why is the lost+found dir so large if it's empty? Linux and UNIX
pre-assigns some inodes
and many data blocks for fsck use - thus the large size.

There is no real " configuration " for lost+found. When a file
system is created, lost+found
is auto created. If for some bizarre reason it was removed - just
recreate it ( as root ),
under the mount point of a system. Of course it MUST be writeable by
root ( 755 ).

Finally - it would really be important for everyone to learn about
inodes and especially
fsck. True - responding "yes" to most of fsck's questions when it
runs, is what most people
do. fsck does automatically clean things up pretty well. I do
NOT recommend
however, to use " fsck -y " anywhere, except is situations where
system boot interruption
( if fsck is waiting for a response ), is not acceptable. While
fsck does clean up
logically well most of the time - blindly saying "yes" to all fsck
questions CAN do more
harm then good is certain situations. Don't get into that habit.
Knowing the basics of inodes
( which everyone should do ), is an important Lunix / UNIX precept and
makes life with fsck
much smoother.

Ahh, but with a robust filesystem, and, of course, most of you know what
you are doing with Linux, or have the desire to learn, you could certainly
set up a RecycleBin directory and set it up to work jsut like an M$
filesystem. It just requires a discipline of dropping your files into the
RecycleBin within your Nautilus workings and as for working within sh/bash,
create an alias for rm that moves the files to your RecycleBin instead of
deleting them.