6

OK, so I've been doing different levels of sysadmin for almost a decade and yet I fell victim to an age old mistake; though I do not understand why it happened.

I was in my server sorting through almost 15 years worth of .tar.gz files uncompressing them and then sorting through the data. I even always used a new folder as a sandbox. I was in a folder (/DATA/RAID1/ROOT/SORTME/BACKOPEN) containing an uncompressed archive of a previous Ubuntu installation when I decided to remove the more obvious system folders I knew I wouldn't need. When I ran my rm it ran to completion but when it was done I had no /bin, /sbin, or any of the other root associated folders named like the ones I tried to remove.

THE OFFENDING COMMAND:

root@dev1:/DATA/RAID1/ROOT/SORTME/BACKOPEN# rm -rfv cdrom/ boot/ bin/ calpp/ dev/ etc/ ldconfig icd-registration.tgz lib/ lib32/ lib64/ opt/ sbin/ selinux/ share/ srv/ usr/ var/

Now, I certainly realize in retrospect that I SHOULD have had ./ before those directories to account for relative path but I am still confused as to why /bin or /sbin would get removed when i specifically designated bin/ sbin/ and was NOT in / at the time.

It seems to me like if I was operating in my pwd and didn't have a preceding forward slash to specify root it should have only deleted the dirs in the directory i was in.

Thank god I didn't have a lone / or any of the names of my ZFS pools in the rm and so I'm fine but I would very much prefer to never make this mistake again.

The idea of botching an OS like this is embarrassing and I can't help but think something other than ./ would be the answer.

What am I failing to notice here?

Thank you in advance for your efforts.

UPDATE:

OK, so I got home and reinstalled 14.04 from the exact same ISO ive been using since release. I re imported my ZFS pools (/DATA/RAID1|/DATA/RAID2) and checked /DATA/RAID1/ROOT/SORTME/BACKOPEN only to find ALL of the dirs/files I specified in the offending command still existed. Not wanting to screw myself all over i copy and pasted the offending command in my post BUT in prepended ./ to each path/file argument. IT WORKED and DID NOT botch my OS. I also redirected the output of the rm -rfv to a file for later examination. No part of my OS got removed, all was well. I am guessing that if hard or symbolic links were the issue I would have had the same issue but did not this time. The plot thickens. I'm getting the feeling I may never get an answer but it seems like maybe this is just one of those things that happened as a freak accident. I can certainly say I will be much more careful in the future...

user809476
  • 69
  • 3
  • 3
    My first guess was that `rm -r` removes symlink targets, but after some research it looks like it doesn't. – wjandrea Mar 21 '18 at 04:18
  • Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :) – user809476 Mar 21 '18 at 04:48
  • 2
    Since you used `-v`, the output would include the files deleted. Examine those. – muru Mar 21 '18 at 06:06
  • Symlinks are not the problem, but hardlinks might be. If ./bin was a hardlink to /bin, removing ./bin would remove /bin as well. – muclux Mar 21 '18 at 07:35
  • OK muclux, that makes some sense if rm follows hardlinks. I didn't know rm followed hardlinks but I should if I'm going to use -rfv of course. Muru, I did check the output of -v and absolutely none of the files removed had / leading on the path. This is my very first post ever to any forum. It was just that weird. I do know one thing, im going to reference . from now on and look for hardlinks. Testing is in my future today for sure... – user809476 Mar 21 '18 at 10:20
  • 2
    Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed. – muclux Mar 21 '18 at 15:13
  • 2
    @user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy – muru Mar 22 '18 at 03:49

0 Answers0