FastCopyはファイルの変更と破損を区別しますか？

[Rakou's Half Life]

デバイスの経年劣化などでファイルが破損することがあると思います。

普段は電源オフの他のドライブX（E, F, G, ...）に対して

Source D:\Sync\

DestDir X:\

という設定で定期的にFastCopyを実行しています。

FastCopyはファイルの変更と破損を区別しますか？

他のスクリプトでチェックサムを取り、よく考えてからFastCopyを実行しないと、

Dのファイルの破損が他のドライブXに伝わってしまいますか？

[SHIROUZU Hiroaki]

経年劣化による、気づかないデータ破壊を「サイレントデータ破壊」とも言うので、そのキーワードで調べてみると良いかもしれません。
通常の破壊では、デバイス側内部で自動エラー訂正されるか、それが出来ない場合は上位に読み出しエラーとして報告します。（Win32の場合は（古来の単純化された）CRCエラーと報告されます）

ただ、それすら掻い潜ってしまう場合も稀に存在します。

（そのために、定期データチェックするファイルシステム（ReFSなど）も存在します）

それはともかく、FastCopyではコピー完了時に、タイムスタンプとハッシュ値をAltStreamに自動記録する機能（ベリファイ情報を付与）があるので、それを有効にした上で、定期的に VerifyInfoList を実行すると定期的なサイレントデータ破壊チェックが行いやすいかもしれません。

https://fastcopy.jp/help/fastcopy.htm#fc_verify

https://fastcopy.jp/help/fastcopy.htm#VerifyInfoList

（なお、それらを行わないで壊れたままのファイルを使うとそれがコピーされます。上位側にはそれが正しいデータと見えるため）

2021年6月10日木曜日 21:11:01 UTC+9 Rakou's Half Life:

[Rakou's Half Life]

ありがとうございます。そういう一般的な話は知りませんでした。ためになります。

v3.90で、:fc_verifyがつくようになったのですね。

教えて頂いた設定をすると、新しいファイルを同期したら、同期先に:fc_verifyがつくのが分かりました。メモ帳で見ました。

また質問させてください。

VerifyInfoListでサイレントデータ破壊チェックが行いやすいというのはつまり、

VerifyInfoListは、実行時にファイルから読み取ったベリファイ情報(ftime, ハッシュ値）と、記録済みの:fc_verify(ftime, ハッシュ値)とを比較して、ftimeが同じなのにハッシュ値が異なる場合はエラーとして報告しますか？

最新のFastCopyには、既存のファイルに:fc_verifyだけをつけて回る機能はありますか？

（質問の意図は、もし:fc_verifyだけをつけて回れると、同期のあとSourceに何の変更もない状態でリストアップ+Vを実行した場合に限って、

今までは:fc_verifyをつけられないバージョンのFastCopyで同期していて、長らく更新していないファイルのサイレントデータ破壊をチェックできて便利そう、です。

正常なら、なにもリストアップされないはずという）

いったん:fc_verifyをつけられれば、あとはVerifyInfoListが便利ですね。

（サイレントデータ破壊のチェックの話は、あまり長くなるとFastCopyの趣旨からけっこう逸脱してしまうような気もしますが…）

2021年6月15日火曜日 21:12:00 UTC+9 shir...@gmail.com:

[SHIROUZU Hiroaki]

現在のFastCopyで可能なのは、

・ベリファイコピーが成功すると :fc_verifyを付与するオプション

・:fc_verifyを列挙表示する

の２つだけです。

（必要な情報は記録したので、あとはユーザ側でどう活用するかはお任せという形）

2021年6月21日月曜日 16:37:52 UTC+9 Rakou's Half Life:

[Rakou's Half Life]

なるほど！ありがとうございます。活用させていただきます。

2021年6月22日火曜日 20:54:36 UTC+9 shir...@gmail.com:

[Kengo Sawatsu]

こんにちは、通りすがりのレスパスビジョンの澤津というものです。

白水氏がおっしゃっている「 サイレントデータ破壊」ですが、HDD内部のプラッタ上でこっそり進んでいる事が多いです。

よくあるケースでは「数年ぶりにHDDからデータを引き出そうとすると、当該データが引き出せずにfastcopy上でCRCエラーリターン表示」とかです。

弊社では上記のようなケースを避けるため、常時アクセスするデータでは各社のRAIDカードが持っている

「定期的にHDD上の不良セクタをチェックして、問題があれば他HDDのパリティ差分から再生成して再配置」の機能「ボリュームチェック」を使ってチェックしています。

これはファイルシステムより下のレイヤでRAIDカードが独自に処理するため、システムを選ばずにサイレントデータ破壊を防止できます。

ただ、個人の単体HDDの場合は同様のことはできないので、定期的に取り出して全ハッシュ値を再算出ー＞突合せするしかないということになります。

個人でコストをかけずに備えるとすると、RAID1くらいしかないのかなという気はしています。（片方から読み出せなくても、もう片方から読み出せる可能性に賭ける）

もしくはGoogleやdropbox,onedriveなどのクラウドバックアップサービスに投げるかですね。

2021年6月26日土曜日 6:43:34 UTC+9 Rakou's Half Life: