🚀 go-pugleaf

david Bowie <dbowie@turing.une.edu.au> writes:

> Listed below are a selection of files stubbornly residing in
> /lost+found. I've managed to remove most of
> them but still over 1000 remain.

These will be corrupt, immuable, device inodes.  You can only get rid
of them with a low-level filesystem editor (see previous posts on the
topic) as chattr does not work on device inodes for non-existant
devices.

My advice is that unless you are running low on inodes (do "df -i")
that you simply move them to a graveyard directory and forget about
them.

-- 
    \\   ( )   No Bullshit!   | Email: B.A.McCauley@bham.ac.uk
 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)
.__/  \\ /\@  /~)  /~[   /\/[ |   +44 121 627 2173 (voice) 2175 (fax)
.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/
###LL  LL\\ (Brian McCauley)  | Finger: bam@wcl-rs.bham.ac.uk

Brian McCauley wrote in message ...
>david Bowie <dbowie@turing.une.edu.au> writes:
>
>> Listed below are a selection of files stubbornly residing in
>> /lost+found. I've managed to remove most of
>> them but still over 1000 remain.
>
>These will be corrupt, immuable, device inodes.  You can only get rid
>of them with a low-level filesystem editor (see previous posts on the
>topic) as chattr does not work on device inodes for non-existant
>devices.

The only way to really clear these is to boot up single user
mode with the disk unmounted (or mounted read-only if it's the
root filesystem). Make a list of the file (The #nnnn number is
the inode number, you can confirm this by doing ls -i) inodes
into a file. Edit the file so that it's a list of commands like

    clri <inode-number>

With with <inode-number> replaced by the inode number of
the file, of course. You can do this by...

    cd /lost+found ; ls -i | awk '{print $1}' | sed -e '1,$ s/^/clri /'
>script_file

Then run debugfs with the -w and -f option to clear the inodes.
When debugfs exits, run a full e2fsck. This should detect the now
unreferenced files from lost+found and remove them.

    debugfs -w -f script_file
    e2fsck -fvy /dev/...

I had a machine once that use to mangle the news spool once a
week (turned out to be memory problems). Anyway this proceedure
became second nature.

Oh yeah, almost forgot the disclaimer. What you are about to do
is serious black magic so anything you trash is your own
responsibly. :) Make sure to read up the man pages first.

>My advice is that unless you are running low on inodes (do "df -i")
>that you simply move them to a graveyard directory and forget about
>them.


That's certainly the easiest way :)

Cheers.
--   .   +-------------------------------------------------------+
 ,--_|\  | John Saunders    mailto:John.Saunders@scitec.com.au   |
/  Oz  \ | SCITEC LIMITED   Phone +61294289563  Fax +61294289933 |
\_,--\_/ | "By the time you make ends meet, they move the ends." |
      v  +-------------------------------------------------------+

I wonder, would it be dangerous to do rm -r lost+found from / as root, then
mkdir lost+found?

david Bowie wrote:

> Listed below are a selection of files stubbornly residing in
> /lost+found. I've managed to remove most of
> them but still over 1000 remain.
>
> The remaining files do not respond to rm '#1234'. Sometimes I may be
> prompted with 'Overiding mode 2152? or 3750?' but I am then informed
> 'rm: #1234: Operation not permitted.'.
>
> I've even tried the following code (dredged from a french newsgroup,
> although I can't read French):
> #include  <uninstd.h>
> main (){
>     unlink ("/lost+found/#1234");
>     }
>
> Chattr -i was something else someone suggested, but doesn't work.
>
> After trawling through all the news groups, I'm at an end.
>
> Any solutions gratefully accepted.
>
> The real problem (why does this keep happening every two weeks) also
> remains a mystery.
>
> Cheers,
>
> David.
>
>   ------------------------------------------------------------------------
> p--xr-s-w-   1 362      15336           0 Jun  5  2031 #167064
> srwxr-s--T   1 13600    32131    2428750080 Jan  8  1968 #167095
> br-xr-xrw-   1 25965    25441    101, 115 Mar 24  1987 #167209
> br-sr-xr-x   1 8713     13362      9,  47 Apr 12 13:07 #167227
> br-xrwS-w-   1 8307     26990     32, 115 Apr  4  1987 #167241
> br-xr-xrw-   1 25965    25441    101, 115 Mar 24  1987 #167249
> c--xr-xrw-   1 30309    29254    110, 117 Apr  8  1987 #167265
> c--xrw--wx   1 26743    26980    114, 101 Sep 17  2028 #167266
> b--srw-r--   1 8293     26996    101, 104 Feb 27  2029 #167267
> c--xr--r-x   1 30055    2675     104, 116 Mar 31  1987 #167268
> c--x-w--w-   1 20291    20302     69,  82 Jul 24  1994 #167274
> b--sr-S--t   1 8308     25972     32, 101 Mar 24  1987 #167280
> br--r----T   1 28257    28257    116,  32 Sep  6  2028 #167281
> c--xr-x---   1 26740    25441    111, 116 Apr  4  1987 #167282
> br-xr--rw-   1 29801    29545    117, 116 Mar 23  2029 #167314
> br-srwSr-x   1 30063    8238     101, 116 Oct 26  2030 #167315
> pr-srw-r--   1 26710    30144           0 Dec 18  1969 #167397
> srwsrwxrwx   1 37059    21334    1793427797 Nov 12  1910 #167401
> prw-rwxrwT   1 4587     2181            0 Dec 12  1934 #167410
> s-w---S-wx   1 34056    63619    2340320731 Jan 27  2032 #167434
> s-w---S-wx   1 36876    17805    40371050 Oct 15  1976 #167444

In linux.redhat.misc david Bowie <dbowie@turing.une.edu.au> wrote:

> Listed below are a selection of files stubbornly residing in
> /lost+found. I've managed to remove most of
> them but still over 1000 remain.
> The remaining files do not respond to rm '#1234'. Sometimes I may be
> prompted with 'Overiding mode 2152? or 3750?' but I am then informed
> 'rm: #1234: Operation not permitted.'.

  Try typing: rm -- /lost+found/* It may works
Let me know the result.

-- 
#######      Greetings from my Computer Planet       ######## 
###                Krzysiek aka Volphy                   ####
#IRC: Volphy #tylkorock         chriss@zeus.polsl.gliwice.pl#
#############*#      no pl fonts, please      #*#############

Phil Reardon <pcr@pcrt.com> wrote:

>I wonder, would it be dangerous to do rm -r lost+found from / as root, then
>mkdir lost+found?

An even more basic question--what are these lost+found directories?
What created them; why? My SuSE 5.2 put them into my dir structure
when I installed it, but they're empty.

--
Howard Arons
To reply change the 1's to lower case L's

Howard Arons wrote in message <3569c8f9.1787147@news.comcation.net>...
>Phil Reardon <pcr@pcrt.com> wrote:
>
>>I wonder, would it be dangerous to do rm -r lost+found from / as root,
then
>>mkdir lost+found?
>
>An even more basic question--what are these lost+found directories?
>What created them; why? My SuSE 5.2 put them into my dir structure
>when I installed it, but they're empty.


They get create when a new filesystem is created. Their purpose
is to hold lost files (the MSDOS equivalent of lost clusters)
that get detected by fsck when it checks the filesystem at boot
time. They are not like a normal directory in that they already
have a chunk of disk space allocated to them to hold entries,
even though they are initially empty. This is because fsck
doesn't want to go allocating blocks to hold directory entries
while the disk is in a scrambled state, otherwise it could do
more damage.

Cheers.
--   .   +-------------------------------------------------------+
 ,--_|\  | John Saunders    mailto:John.Saunders@scitec.com.au   |
/  Oz  \ | SCITEC LIMITED   Phone +61294289563  Fax +61294289933 |
\_,--\_/ | "By the time you make ends meet, they move the ends." |
      v  +-------------------------------------------------------+

/lost+found goes back to the earliest days of Unix.

when a filesystem is made, a directory /lost+found is made
just below the root of that filesystem.

When fsck finds confusion, etc, it puts the remains in /lost+found.

that way, you know where it is....and you can figure out what to
do with it at your leisure.



Howard Arons wrote:
> 
> Phil Reardon <pcr@pcrt.com> wrote:
> 
> >I wonder, would it be dangerous to do rm -r lost+found from / as root, then
> >mkdir lost+found?
> 
> An even more basic question--what are these lost+found directories?
> What created them; why? My SuSE 5.2 put them into my dir structure
> when I installed it, but they're empty.
> 
> --
> Howard Arons
> To reply change the 1's to lower case L's

-- 


Aaron R. Kulkis
Unix Systems Administrator

--------------------------------
I speak for me, not my employer.
--------------------------------

Threads: a poor substitute that you implement in an OS
when it can't handle true context switching properly.

John Saunders wrote:

> Brian McCauley wrote in message ...
> >david Bowie <dbowie@turing.une.edu.au> writes:
> >
> >> Listed below are a selection of files stubbornly residing in
> >> /lost+found. I've managed to remove most of
> >> them but still over 1000 remain.
> >
> >These will be corrupt, immuable, device inodes.  You can only get rid
> >of them with a low-level filesystem editor (see previous posts on the
> >topic) as chattr does not work on device inodes for non-existant
> >devices.
>
> The only way to really clear these is to boot up single user
> mode with the disk unmounted (or mounted read-only if it's the
> root filesystem). Make a list of the file (The #nnnn number is
> the inode number, you can confirm this by doing ls -i) inodes
> into a file. Edit the file so that it's a list of commands like
>
>     clri <inode-number>
>
> With with <inode-number> replaced by the inode number of
> the file, of course. You can do this by...
>
>     cd /lost+found ; ls -i | awk '{print $1}' | sed -e '1,$ s/^/clri /'
> >script_file
>
> Then run debugfs with the -w and -f option to clear the inodes.
> When debugfs exits, run a full e2fsck. This should detect the now
> unreferenced files from lost+found and remove them.
>
>     debugfs -w -f script_file
>     e2fsck -fvy /dev/...
>
> I had a machine once that use to mangle the news spool once a
> week (turned out to be memory problems). Anyway this proceedure
> became second nature.
>
> Oh yeah, almost forgot the disclaimer. What you are about to do
> is serious black magic so anything you trash is your own
> responsibly. :) Make sure to read up the man pages first.
>
> >My advice is that unless you are running low on inodes (do "df -i")
> >that you simply move them to a graveyard directory and forget about
> >them.
>
> That's certainly the easiest way :)
>
> Cheers.
> --   .   +-------------------------------------------------------+
>  ,--_|\  | John Saunders    mailto:John.Saunders@scitec.com.au   |
> /  Oz  \ | SCITEC LIMITED   Phone +61294289563  Fax +61294289933 |
> \_,--\_/ | "By the time you make ends meet, they move the ends." |
>       v  +-------------------------------------------------------+