web-dev-qa-db-ja.com

Robocopy-出力のログ中に問題が発生する可能性はありますか?

私は、Cドライブ(NTFS)からペンドライブ(exFAT)に新しいファイルのみをバックアップするバックアップスクリプトに、Robocopyが適切なオプションになるかどうかを評価しています。

実行しているこのコマンドがあります。それは仕事をしますが、宛先がリムーバブルUSBペンドライブであり、exFATでフォーマットされている場合、ログが正しくないようです。宛先がFATまたはNTFSの場合、この問題は発生しません。

robocopy C:\Temp\F1 D:\F1 /XO /E /FFT /LOG:C:\Temp\robo.txt /NP  /NDL /R:1 /W:3

上記のコマンドD:はペンドライブ文字であり、コマンドまたは.BATファイルは常にWindows 7 Ultimate64の管理者として実行されていました。

この問題は、以下に説明するようにケース2で発生します。

ケース1-ログのスクリーンショットを参照してください。これは正しいようです。コピーされたファイル名はすべてログに記録され、コピー統計は正しいです。 3ファイルがコピーされます。

enter image description here

ケース2-ソースにもう1つのファイルを追加します。現在、この新しいファイルをコピーするだけですが、ログ内のすべてのファイルが表示され、統計が間違っています。 4つのファイルがコピーされたと表示されます。

enter image description here

このタイプの一貫性のないロギングは、宛先がexFATフォーマットのペンドライブである場合にのみ発生します。 FATまたはNTFSに問題はありません。

OS-Windows 7 Ultimate64。

質問。

  1. 宛先がexFATペンドライブの場合、これはRobocopyログの問題またはバグですか?
  2. そうでない場合、これを修正する必要があるコマンドのオプションがありませんか?

これについてさらに明確にしていただければ幸いです。


編集

ケース3-変更はありませんが、4つのファイルすべてがログファイルに一覧表示されます。

enter image description here

/ FFTまたはそれがなくても、ログデータは変更されません。

Free File Syncを使用して確認しましたが、ファイルサイズ、タイムスタンプ、実際の内容に関しては、両方のディレクトリが同期しています。コピーではなく、ログに記録していると思います。

enter image description here


編集2

2つの大きなファイルを一緒に312MBのソースに配置しました。 USB2ペンドライブの宛先にコピーしてから42秒かかります。ログは大丈夫です。

enter image description here

ここで、コマンドを再度実行します。 0秒で終了しますが、それでも2つのファイルがログに記録され、統計には2つのファイルがコピーされたことが示されます。 USB2.0ペンドライブの312MBデータではこれは不可能だと確信しています。

enter image description here

2
rajeev

私のWindows7のRobocopyバージョンは6.1.7601.23403です。

そのバージョンのRobocopyは2009年のものです。10年前のものです。

Windows 10(64)PCからWindows 7(64)にRobocopyをコピーしようとしましたが、コマンドを.BATに入れると、有効なWin32アプリケーションではないというエラーが表示されます。

残念ながら、Windows 7 特定の前提条件がありません 現在のRobocopy実行可能ファイルに必要なため、最新の実行可能ファイルをWindows10システムから単純にコピーすることはできません。

基盤となるコンポーネントがそれをサポートする必要があるため、Windows8からのコピーでさえ機能しません。

Robocopyは、基盤となるファイルシステムコンポーネントを呼び出すユーティリティにすぎません。

enter image description here

最新バージョンのRobocopyを搭載したWindows101903システムでこの問題を再現できませんでした。

問題がコピープロセス自体ではなくログにあることは間違いありません。 Robocopyは実際にはここで想定されていることを正確に実行します、誤って報告するだけです。

ここで見ている瞬間的なコピーは不可能です。あるボリュームから別のボリュームにファイルをコピーするのに最初は42秒かかる場合、同じプロセスは2回目に0秒かかることはありません

最初のファイルコピーの速度を制限するボトルネックが何であれ、それ以降のコピーにまったく同じように影響します(つまり、USB帯域幅とフラッシュドライブの書き込み速度)。

これは、比較的大きなファイルを含むコピージョブを実行し、それにかかる時間を観察してから、宛先ドライブから大きなファイルを削除して同じジョブを再実行することで簡単に実証できます。 2つの異なるボリュームにわたる後続のコピーには、ほぼ同じ時間がかかります。

ログの不一致:

  • 緑=真。

  • 赤=偽。

enter image description here

最初の緑色のボックスに表示されている内容を明確にするために、「100%新しいファイルがありません」行を追加して、空白を表示するためにログが正しい場所を示しました。これらのファイルのコピーが実際に行われた場合、正常にコピーされた各ファイルの横に「100%」と「新しいファイル」が表示されます。

これらのファイルのコピーは発生しませんでした。 OPはそこに20GBのデータを入れることができ、Robocopyはそれでも瞬時の転送を報告します!

結論:

Windows 7は2009バージョンより新しいものを使用できないため、OPはRobocopyのバージョンをアップグレードできません。

彼の当面の選択肢は、XCOPYまたはその他のファイルコピーユーティリティを使用することです。

OPが最終的にWindows10などの新しいバージョンのWindowsにアップグレードすると、この古いバグにパッチが適用された最新バージョンのRobocopyが使用され、このログの不具合は発生しなくなります。

2
Mr Ethernet

Robocopyは、異なるファイルシステム間でファイルを転送するときに問題を引き起こすことが知られています。 NTFSは64ビットのタイムスタンプであるため、ex fatは3つの個別のフィールドを使用してタイムスタンプを格納し、1バイトがUTC時間のタイムゾーンになります。

そして、要約に正しい情報が表示されないサーバーの例があります 例:ここ 。要約計算は(大まかに)コピー手順に直接統合されていないので、何らかのバグがあります。しかし、これを証明する「公式」文書は見つかりませんでした。また、ログと要約のどちらが実際に正しいかを確認したい場合もあります。

1
Albin