Re: cleaning up lost+found
Once upon a time, when I was working with UNIX version 7, I had a case
where I could not clean up a disk using fsck. I used a program called
(as I remember) 'clri' to wipe out the inode, then did an fsck to clean
up the "orphans" that I had created.
'clri' doesn't exist anymore, that I know of (fsck is supposed to be
good enough to handle everything;-). But I did find a disk editor on
the Debian site that allows you to write to inodes, "lde 2.4-4", in the
packages list for slink. Maybe you could clean things up with it? Note
that I have never used it and have no idea how safe it is to use. Also,
you need some knowledge of FS concepts. And if you do this, BOOT FROM a
rescue floppy and DO NOT mount the disk you are going to work on.
As a side note, the program header info also states that it can be used
to find data blocks for deleted files and dump them to a regular file in
another location. There was another post (since deleted) asking for
help in recovering deleted files, this might help.
Olaf Meeuwissen wrote:
> "Petr [Dingo] Dvorak" <firstname.lastname@example.org> writes:
> > On Wed, 26 Jul 2000, Lehel Bernadt wrote:
> > LB> On 26-Jul-2000 Olaf Meeuwissen wrote:
> > -- snip --
> > OM> in /home/lost+found that I can't seems to remove. Not even as root!
> > -- snip --
> > LB> They probably have the immutable attribute set. Remove it with chattr.
> > I have the same problem, mine happened after the machine got nudged by power
> > outage:
> > cr-Srw-r-- 1 25402 29706 115, 58 Oct 9 1999 fontsmpl.sty
> > i tried to use chattr to change the attributes:
> > warlord.root /lost+found/bad_device # chattr -c -S fontsmpl.sty
> > chattr: No such device while reading flags on fontsmpl.sty
> > but no such luck, i tried about every destructive command i can think of, but
> > this thing is impervious to everything what i throw on it :)
> Same thing here. Actually, I get some other reponses as well.
> chattr: Inappropriate ioctl for device while reading flags on <filename>
> chattr: Invalid argument while reading flags on <other_filename>
> chattr: No such device while reading flags on <yet_another_filename>
> The total number of messages equals the total number of files I try it
> on, so there are no files that cause multiple messages. I've looked
> for a pattern in the file permissions of the files associated with the
> same error message, but if there is one I didn't see it.
> If someone has any clues I'd like to know. If necessary I can mail
> whatever extra info you think you need. TIA,
> Olaf Meeuwissen Epson Kowa Corporation, Research and Development
> Unsubscribe? mail -s unsubscribe email@example.com < /dev/null
Staff Software Quality Engineer