
さて、私はほぼ 10 年間、さまざまなレベルのシステム管理を行ってきましたが、それでも昔からの間違いの犠牲になってしまいました。なぜそうなったのかはわかりませんが。
私は自分のサーバーで、ほぼ 15 年分の .tar.gz ファイルを解凍してデータを整理していました。サンドボックスとしては常に新しいフォルダーを使用していました。/DATA/RAID1/ROOT/SORTME/BACKOPEN
以前の Ubuntu インストールの解凍されたアーカイブを含むフォルダー ( ) にいたときに、必要ないとわかっているシステム フォルダーを削除することにしました。 を実行すると、完了まで実行されましたが、完了したときに、、 、または削除しようとした名前の他のルート関連フォルダーはrm
存在しませんでした。/bin
/sbin
問題となっているコマンド:
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/
./
今、振り返ってみると、相対パスを考慮してそれらのディレクトリを以前に用意しておくべきだったと確かに認識していますが、具体的に指定したのにその時点ではいなかったのに、なぜ削除されるの/bin
かまだわかりません。/sbin
bin/ sbin/
/
私の考えでは、pwd で操作していて、ルートを指定するための先頭のスラッシュがなかった場合、私がいたディレクトリ内のディレクトリのみが削除されるはずだったようです。
/
ありがたいことに、ZFS プールの名前は 1 つもなかったのでrm
大丈夫ですが、二度とこのような間違いは起こさないほうがいいと思います。
./
このように OS を台無しにするのは恥ずかしいことであり、何か他の方法が答えになるのではないかと思わずにはいられません。
ここで私が気づかなかったことは何でしょうか?
どうぞよろしくお願いいたします。
アップデート:
よし、家に帰って、リリース以来ずっと使っていた ISO から 14.04 を再インストールしました。ZFS プール (/DATA/RAID1|/DATA/RAID2) を再インポートし、/DATA/RAID1/ROOT/SORTME/BACKOPEN をチェックしたところ、問題のコマンドで指定したすべてのディレクトリ/ファイルがまだ存在していました。面倒なことはしたくなかったので、問題のコマンドをコピーして自分の投稿に貼り付けましたが、各パス/ファイル引数の前に ./ を付けました。うまくいきましたし、OS に支障はありませんでした。また、rm -rfv の出力を後で調べられるようにファイルにリダイレクトしました。OS のどの部分も削除されず、すべて順調でした。ハード リンクまたはシンボリック リンクが問題であれば、同じ問題が発生したと思いますが、今回は発生しませんでした。話は複雑になります。答えは永遠に得られないかもしれないという気がしますが、これはたまたま起こった出来事の 1 つなのかもしれません。今後はもっと注意することになるだろうと断言できます...