仮想化エンジニア奮闘記

Citrix や VMware といったサーバー・デスクトップ仮想化の最新技術や設計情報の検証結果を共有します。(本ブログは個人のものであり、所属する会社とは関係ありません。)

UNCパスのファイルをdel処理する時は気をつけろ!

みなさまお疲れ様です。

最近は思いついたものを色々記事にしており、仮想系の記事が少ないですがすみません。

 

今回は Windowsバッチ や Powershell 等でUNCパスのファイルをdel処理で削除する際に気をつけた方がよいことを記載します。さっそく結論です。

pushd や cd 等でUNCパスに移動をしてdel処理を流す際は、移動がエラーになっていないか必ず分岐処理を入れること。エラーになっていた場合は、del処理を行わないこと。

 

例えば下記のような2つの処理を行っているスクリプトを考えてみます。

①ログなどのファイルをリモートのファイルサーバーにコピーする

②ログがたまり続けないように一定期間経過したファイルサーバー上のファイルは、スクリプト実行サーバーからローテーション処理をかける

 

f:id:kenta53682:20170618125415p:plain

 

forfilesでUNCパスはサポートされていないため、「pushdしてdel処理を行う」ことを考えるかと思います。

が、上記のスクリプトだと、pushdに失敗した時の条件分岐が入っていないので、pushd失敗時はデフォルトの作業ディレクトリで削除処理が走ります。

 

タスクスケジューラでは作業フォルダを指定しない場合、「C:\windows\system32」が作業フォルダとなります。(taskschd.mscがある場所だからだと思います。)

 

もうお分かりかと思いますが、pushd失敗時 (ファイルサーバーがシャットダウンされている場合など) はスクリプト実行サーバーの「C:\windows\system32」配下のファイルが削除される処理が走ります これはやばい笑

 

このような悲しいことが起きないよう、少なくとも①だけは必ず守りましょう!

①pushd や cd 等でUNCパスに移動をしてdel処理を流す際は、移動がエラーになっていないか必ず分岐処理(if)を入れる

②タスクスケジューラの「開始(オプション)」にて作業ディレクトリを明示的に指定する (or スクリプトの最初で必ず作業ディレクトリにcdする)

③forfilesでdel処理を行う場合、del対象の名前や拡張子が決まっている場合、「/m [ファイル名]*.[拡張子] のようにマスクを入れる

 

ちなみに、なぜこれを記事にしているかというと直近で私が「system32配下のファイルが削除される」問題を引き起こしてしまったからです。

OSリストアが必要となる大問題なので、スクリプト作る人もレビューする人も絶対条件分岐が入っているか意識して下さい。