none
RobocopyとThumbs.db RRS feed

  • 質問

  • Robocopyで/Bオプションを付加して管理者モードで実行すると、Thumbs.dbがコピーに失敗するように見えます。

    Thumbs.dbでひっかかり、リトライを繰り返しますが成功しません。

    しかし/Bを付けずに管理者権限を持つ管理者以外のアカウントで実行したところコピーできました。

    これは仕様でしょうか?

    それとも私の環境上の別の要素が邪魔をしたのでしょうか?

    2012年12月1日 0:07

回答

すべての返信

  • Robocopyで/Bオプションを使う場合について、以下のような KB がありますが、エラー内容など関連していないか確認されていますか?

    "Robocopy /B" does not copy the security information such as ACL in Windows 7 and in Windows Server 2008 R2
    http://support.microsoft.com/kb/979808/en-us


    hebikuzure

    • 回答の候補に設定 星 睦美 2012年12月4日 8:27
    • 回答としてマーク 星 睦美 2012年12月6日 2:22
    2012年12月1日 13:45
  • ご回答ありがとうございます。

    頂いた先の説明を見ると現象的には、コピーには成功するけれどアクセス権がコピーされない、とあります。

    ちょっと違うみたいですね。

    ただ、今回はコピー先が安価なLinuxベースの家庭用NASで、ファイルシステムもNTFSではありませんでしたから、

    コピー先がローカル内かWindows系のコンピュータなら、結果が違った可能性もなくはないかもしれませんけど。

    その他今回のRobocopyでは、コピーするフォルダの名前に「&」が入っており、これが原因で成功しませんでしたので、

    「""」で挟み回避しました。

    コピー自体の安定性は高いのですが、こういうところが惜しいですね。

    2012年12月1日 22:20
  • 特殊文字 (別な意味を持つ可能性のある文字)を含むファイルやフォルダーをコマンドの引数に利用する際は引用符でくくる、というのは仕方ない制限事項でしょう。

    そうでないと利用不可の文字がやたらと増えてしまいますから.....


    hebikuzure

    2012年12月2日 5:58
  • コメントありがとうございました。

    しかし本件に関する限り私にはそうは思えません。

    ファイル名やフォルダ名は禁則文字がきちんと決められており、「&」はそれには該当しません。

    ツールが禁則文字でもない有効な名前を解釈できないというのはおかしいと思います。

    しかもMSのツールなんです。

    ある時は有効ある時は無効を認めるなら、MSが定めたルールに一貫性が無いことになります。

    使う側が色々な難を逃れる為、念の為""で挟んで配慮しておく、というのはおかしくありませんが、

    こういう一貫性の無さは問題です。

    ""で挟まないと判別されないというのは、

    経験的にはスペースが含まれるファイル名やフォルダ名のあるパスを記述する場合のみでした。

    ""が無いと、どこまでがパスの記述か判別できないからです。

    これは文法上の解釈が一義に定まらないので、そのように記述しないと解釈されないというのはおかしくありません。

    しかし、Robocopyで「&」を特別扱いするのは非常におかしな例外に見えます。

    そうしなければならない根拠も、メリットもあるようには見せません。


    2012年12月2日 15:27
  • "&" はファイル名としては使えますが、コマンドラインだと複数コマンド記述の区切り文字として扱われちゃうからではないかなあ。
    (すみません、投稿している環境の関係で未検証ですが...)


    hebikuzure

    2012年12月3日 2:05
  • ご指摘ありがとうございます。
    copyで実験したところ、同じような現象が出ました。
    調べるきっかけを頂いたおかげでコマンドラインでの「&」と「&&」について知識がメンテされました。

    30年以上前から使ってますがコマンドラインの「&」と「&&」については初めて知りました。
    一貫性はあったんですね、MSさんケチをつけてごめんなさい。

    2012年12月3日 21:18
  • 失敗したときは、たまたま誰か(というか explorer.exe)が排他オープンしていたのでは?
    2012年12月3日 21:52