Messages in this thread | | | From | "tzanger" <> | Subject | Re: undeletable files in /lost+found | Date | Tue, 16 Jun 1998 09:22:52 -0400 |
| |
>[root@eiterra /lost+found]# ls -la |more >total 3769209649 >br-s-wsrwx 1 29541 14385 117, 110 Jun 1 1975 #28945 >b--Sr-srwT 1 29797 28265 50, 48 Aug 15 1995 #28946 >br-s-wsrwx 1 29541 14385 117, 110 Jun 1 1975 #29081 >b--Sr-srwT 1 29797 28265 50, 48 Aug 15 1995 #29082 > >In short; ls -l is broken severely in debugfs, one. And two, when your >filesystem looks like THAT, it may end up being easier to mkfs.ext2 yer >drive. ;P
Not true... I had bad fs corruption once (power outage and I was doing some heavy file operations) -- needless to say fsck had a field day with the drive, and I ended up with a directory listing MUCH larger than that (about 50 files, all with REALLY screwy attributes, dates, sizes...) I ended up with e2fstools I believe, manually deleting the inodes and forcing e2fsck to ignore what it thought was right and just delete 'em, DAMMIT! :-) It took hours until I figured out how to manually unlink the inodes in the map with e2fsprogs. every time I erased the files from the directory, e2fsck would recreate them. but it's all better now.
Needless to say, I lost everything it was working on, but I did keep the fs and the unchanged data.
In retrospect, would it not be possible to unset the immutable attribute bit, then give the files a sane mode (444?) THEN use debugfs or something to nuke them? I think the biggest problem with my corrupt files was I had no idea there WAS such a thing as an immutable bit. "Waddaya mean, operation not permitted?? I'm ROOT!"
There was MUCH screaming and gnashing of teeth that day. :-) Mind you there was also excellent documentation on ext2. :-)
Andrew
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |