Skip to main content
Welcome guest. | Register | Login | Post

rm -rf of data on usb stick leads to crunching of harddisk: what the hell?

3 replies [Last post]
tbuitenh's picture
Offline
Joined: 2005-12-21

I tried to remove some data (some damaged files and a bootable slax, actually) from a USB stick using rm -r. That didn't work (permission denied) so I tried it again as root. Permission denied again. Okay, rm -rf it then. This led to a long stream of garbled filenames (also permission denied) and a lot of crunching on my harddisk. And the system wasn't swapping... What the hell?

I did a dosfsck -a /dev/sdb1 on the stick, it turned out the filesystem was so damaged automatic repair would take ages, so I stopped that. I did mkfs.vfat -c -v /dev/sdb1 instead, which seemed to go alright. I copied some files to it, and checked the filesystem:

[root@garden tb]# dosfsck -a -v /dev/sdb1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   2060288 bytes per FAT (= 4024 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4136960 (sector 8080)
    515018 data clusters (2109513728 bytes)
62 sectors/track, 66 heads
         0 hidden sectors
   4128224 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
Free cluster summary wrong (515017 vs. really 514969)
  Auto-correcting.
Performing changes.
/dev/sdb1: 4 files, 49/515018 clusters

I copied my photo collection to it, and checked again:

[root@garden tb]# dosfsck -a -v /dev/sdb1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   2060288 bytes per FAT (= 4024 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4136960 (sector 8080)
    515018 data clusters (2109513728 bytes)
62 sectors/track, 66 heads
         0 hidden sectors
   4128224 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
Free cluster summary wrong (514969 vs. really 335456)
  Auto-correcting.
Performing changes.
/dev/sdb1: 543 files, 179562/515018 clusters

It would seem that this "Free cluster summary wrong" problem is nothing to worry about, looks like Linux just doesn't update it. Apart from that, the stick seems fine, right?

Now I'm a bit worried if anything is missing from my system. I looked around a bit and everything seems to be there. Any hints for how to do a quick check that is more thorough than just looking around?

Being root + rm -rf + lots of noise on the disk = scary!

tbuitenh's picture
Offline
Joined: 2005-12-21
Unfortunately there ARE

Unfortunately there ARE files missing from my system now. Nothing essential, though, just most of secondlife, which I reinstalled.

If there is anything else missing I guess I'll just bump into it and reinstall whatever package got damaged.

Lesson learned: don't do rm -rf as root on a filesystem that looks damaged. This kind of thing shouldn't happen though: why on earth did rm jump from one filesystem to another?

Offline
Joined: 2007-09-10
I agree this shouldn't

I agree this shouldn't happen. :/
Maybe you should file a bug report: http://www.gnu.org/software/coreutils/

tbuitenh's picture
Offline
Joined: 2005-12-21
I should have kept the

I should have kept the weird output of rm, now I have nothing remotely useful to put in the report. It's not even certain that it did indeed jump to a different place, the missing parts of secondlife might as well be caused by a bug in the package manager (arch's pacman) or yet something else. Who knows.

I think the crazy filenames in the corrupted filesystem on the stick caused a buffer overflow that made rm go delete something else, I might have a look at the sourcecode of rm sometime to see if that is possible. But not now, I'm too busy.

Comment viewing options