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...
7 Reset to default
