ベリファイで失敗（間違い）することが、ありますか？(Ver 3.25)

[asccssac...@gmail.com]

いつも重宝しております

有難うございます

「環境」

Windows 10 Anniversary Pro 64bit

FastCopy325_x64.zip ←FastCopy.exe

ベリファイで失敗（間違い）することが、ありますか？

単にうちだけの問題で他のPCでは起きないと

思いますが、、

「症状」

FastCopy.log　ログファイルには「ErrFiles : 0」

↓　なのに

A)cert8.db.fc_verify_err

B)extensions.json.fc_verify_err

とエラーファイルが２つできています

「詳細」

しかも、ファイル比較ソフト２つを使って比較したところ

B)ファイルは同一（内容一致）◎でした。。

「比較結果」

■v3.11　ベリファイ時、相違があった場合はファイル名末尾に .fc_verify_err を付与してリネーム。

A)-----------------[59 byteまで一致]（内容不一致）×　確かに

cert8.db

cert8.db.fc_verify_err

-----------------

B)-----------------同一（内容一致）◎

extensions.json

extensions.json.fc_verify_err

-----------------

「使用したファイル比較ソフト」

CompFile.exe　←高速ファイル比較ツール1.03

C:\winmerge-2.14.0-jp-118-x64-exe\WinMerge\WinMergeU.exe

----------------------------------------------------------参照

■FastCopy.log　ファイル

=================================================

FastCopy(ver3.25) start at 2016/10/29 18:32:39

<Source>  C:\Users\〇〇\AppData\Roaming\Thunderbird

<DestDir> D:\backup20161029\

<Command> 差分（サイズ・日付） (with Verify)

-------------------------------------------------

 No Errors

TotalRead  = 19,906 MB

TotalWrite = 19,906 MB

TotalFiles = 531 (46)　▼

TotalTime  = 05:43

TransRate  = 58.0 MB/s

FileRate   = 1.55 files/s

VerifyRead = 19,906 MB

VerifyFiles= 531

Result : (ErrFiles : 0 / ErrDirs : 0)  ←エラー０ですが、、？？▼

----------------------------------------------------------参照

単にThunderbird（19G）データを

C: 例のSSD Samsung 840 EVO

↓

D: 例のHDD(東芝 2T MD04ACA200)

にコピーしただけです

「注意」

「差分（サイズ・日付）」としていますが、

↓

元々何もないフォルダにコピーしていますので

（\backup20161029\　←は空フォルダ）

↓

１００％新規作成コピーになります

「参考」

Thunderbird\ フォルダ内　プロパティ表示では

ファイル数：531、フォルダ数：45● サイズ：19.4GB

▼TotalFiles = 531 (46)　←46フォルダ？と表示しているのは

45の間違いですか？？？

「考察」

C: 例のSSD Samsung 840 EVO　

←SMART値など特に問題はないようですが

　いつも相性が悪い？と勝手に思っています

D: 例のHDD(東芝 2T MD04ACA200)

←SMART値など特に問題はないようですが

何かわかりましたらお願いします

[asccssac...@gmail.com]

言い忘れました

ハッシュ方法：SHA-1 ←●デフォルトです

B)-----------------同一（内容一致）◎

extensions.json

extensions.json.fc_verify_err

-----------------

↓

B)-----------------SHA-1●　一致◎

extensions.json

extensions.json.fc_verify_err

-----------------

念のためにハッシュ（SHA-1）値比較したら

やはり同じでした

■HashTab_v6.0.0.28_Setup.exe　で確認

[asccssac...@gmail.com]

なお

7月 5日　ベリファイエラーについて質問しましたが、、

以下認識で合っていますか？？

1)ベリファイ　　一致の場合◎

------------------

１．srcファイルを読み込み

２． → 読み込みデータをハッシュ値計算（メモリ上に記憶）

３． → 読み込みデータをdstファイルに書き込み

　（他のファイルについても１～３を実施、２用のメモリ領域が一杯になるまで。1万～数万ファイル程度）

４．dstファイルを読み込み

５．→ 読み込みデータのハッシュ値計算

６．上記５のハッシュ結果が２のハッシュ値を比較し、◎同一の場合

　　↓

７．完了←「dstファイル」正常作成済

------------------

2)ベリファイ　不一致の場合×

------------------

１．srcファイルを読み込み

２． → 読み込みデータをハッシュ値計算（メモリ上に記憶）

３． → 読み込みデータをdstファイルに書き込み

　（他のファイルについても１～３を実施、２用のメモリ領域が一杯になるまで。1万～数万ファイル程度）

４．dstファイルを読み込み

５．→ 読み込みデータのハッシュ値計算

６．上記５のハッシュ結果が２のハッシュ値を比較し、×異なる場合、.fc_verify_err にリネーム

　　↓

７．上記「srcファイル」を再度コピー●

　　↓

８．完了←「dst.fc_verify_err」←異常ファイル▼と「srcファイル」（←オリジナル）の２つ作成済

------------------

■つまり不一致の場合には、ファイルが１つ増える

src　　　　　　　　←バックアップ用に再度作る　←この分１つ増える

dst.fc_verify_err　←異常であることを知らしめるために、あえて作っておく

「疑問」ですが、一度コピーに失敗したのに、再度「srcファイル」を

　　　　コピーしても、この再度コピーした「srcファイル」は信頼できる

　　　　のでしょうか？？

　　　　↓

　　　　もしや別ロジックで再度コピーしているのですか？？

　　　　例えば、内部で「xcopy」コマンドを利用してコピーするなど

------------------

この認識で合っていますか？？

実は、、以前から疑問でした。。。

------------------------------------------------------------------参考

■ベリファイエラーについて  7月 5日　質問 

------------------------------------------------------------------

ご参考までに、もう少し細かく書くと下記のような処理を行っています。

（それぞれが、別スレッドでパイプラインのように並列処理されます）

１．srcファイルを読み込み

２． → 読み込みデータをハッシュ値計算（メモリ上に記憶）

３． → 読み込みデータをdstファイルに書き込み

　（他のファイルについても１～３を実施、２用のメモリ領域が一杯になるまで。1万～数万ファイル程度）

４．dstファイルを読み込み

５．→ 読み込みデータのハッシュ値計算

６．上記５のハッシュ結果が２のハッシュ値を比較し、異なる場合、.fc_verify_err にリネーム

------------------------------------------------------------------

[Hiroaki SHIROUZU]

おそらく、xxx.db は読み込んでいる最中に中身が変更されたのだと思います。

.json の方は不明ですが、ログに下記のような出力があるはずですので、

Verify Error src:(hash_val) dst:(hash_val)  : (file_name)

その2つのハッシュ値とファイルサイズを書いていただけますか？

また、正しいのはsrc/dstのうち片方だけのはずですが、src/dstのどちらが正しいかわかりますか？

なお、ベリファイエラーが出たファイルへの処理は、エラー出力と dstを .fc_verify_errにリネームするだけです。

（改めてのコピー等は行いません）

[asccssac...@gmail.com]

>おそらく、xxx.db は読み込んでいる最中に中身が変更されたのだと思います。

確かに、薄々そう思っていました。。

>.json の方は不明ですが、ログに下記のような出力があるはずですので、

>Verify Error src:(hash_val) dst:(hash_val)  : (file_name)

>その2つのハッシュ値とファイルサイズを書いていただけますか？

いいえ

ありません

ログファイルは先ほど書いた通りです

再度貼り付けます

----------------------------------------------------------参照

■FastCopy.log　ファイル

=================================================

FastCopy(ver3.25) start at 2016/10/29 18:32:39

<Source>  C:\Users\〇〇\AppData\Roaming\Thunderbird

<DestDir> D:\backup20161029\

<Command> 差分（サイズ・日付） (with Verify)

-------------------------------------------------

 No Errors

TotalRead  = 19,906 MB

TotalWrite = 19,906 MB

TotalFiles = 531 (46)　▼

TotalTime  = 05:43

TransRate  = 58.0 MB/s

FileRate   = 1.55 files/s

VerifyRead = 19,906 MB

VerifyFiles= 531

Result : (ErrFiles : 0 / ErrDirs : 0)  ←エラー０ですが、、？？▼

----------------------------------------------------------参照

>また、正しいのはsrc/dstのうち片方だけのはずですが、src/dstのどちらが正しいかわかりますか？

いいえ

オリジナル側つまり C: 「src」はすでに削除してしまいました

まさかエラーが起きているとは、知らなかったので。。残念です。。

ファイル比較は「コピー先フォルダ」（D:\backup20161029\）の２つづつ、２組で

行ったわけです。。

A)

B)

>なお、ベリファイエラーが出たファイルへの処理は、エラー出力と dstを .fc_verify_errにリネームするだけです。

>（改めてのコピー等は行いません）

そうですか。。変ですね。。

１）

エラー出力　←書いた通り、画面に表示ありませんでした▼

エラー出力　←書いた通り、ログファイに書き出しはありませんでした▼

２）（改めてのコピー等は行いません）

以下の通り、改めてのコピー　はあります。。に見えますが、

間違いですか？

■D:\backup20161029\　内

A)-----------------[59 byteまで一致]（内容不一致）×　確かに

cert8.db　　　　　　　　←改めてのコピー　しました●

cert8.db.fc_verify_err　←リネーム　しました●

-----------------

B)-----------------同一（内容一致）◎

extensions.json　　　　　　　　←改めてのコピー　しました●

extensions.json.fc_verify_err　←リネーム　しました●

-----------------

（改めてのコピー等は行いません）なら、、、

▼ないはずの

cert8.db

extensions.json

2つがコピー先に存在します。。。

どうしてですか？？

「更新日時」

↓　

■D:\backup20161029\　内

A)-----------------[59 byteまで一致]（内容不一致）×　確かに

cert8.db　　　　　　　　←2016/10/29 13:38

cert8.db.fc_verify_err　←2016/10/25  5:51▼

-----------------

B)-----------------同一（内容一致）◎

extensions.json　　　　　　　　←2016/10/29  7:29

extensions.json.fc_verify_err　←2016/10/25  5:51▼

-----------------

↓ 

更新日時　がこうなっていました。。

fc_verify_err　←2016/10/25  5:51▼

が２つ同じ「更新日時」ですが、、

偶然でしょうか？？

 

[Hiroaki SHIROUZU]

１．ベリファイエラーのログが出ていないこと

２．タイムスタンプが古いこと

３．正しくコピーされたファイルが存在すること

という３点はいずれも1回のコピー＆verifyでは（作り的に）ほぼ発生しえないですね。

最後のコピー時にはベリファイエラーは発生しておらず、.fc_verify_errは以前（10/25～10/29のどこかの時点）のベリファイエラーの残骸ではと思います。

バックアップ先が今回が初めてのコピーであれば、たとえば、src側に.fc_verify_errファイルが存在していた、といったことはありませんか？

また、fastcopy.log は消さない限り追記されていきますので、10/25～10/29の間でベリファイエラーの記録が残っていないかご確認ください。

また、ファイルログを取るようにしていれば、（異常はもちろん）正常終了した個々のファイルコピー＆ハッシュ値記録も残りますので、src側に存在していた.fc_verify_errを通常ファイルとしてコピーしていた、といった情報も残っているはずですが、どうでしょうか？

[asccssac...@gmail.com]

有難うございます

>１．ベリファイエラーのログが出ていないこと

>２．タイムスタンプが古いこと

>３．正しくコピーされたファイルが存在すること

>という３点はいずれも

>1回のコピー＆verifyでは（作り的に）ほぼ発生しえないですね。

>最後のコピー時にはベリファイエラーは発生しておらず、

>.fc_verify_errは以前（10/25～10/29のどこかの時点）のベリファイエラーの残骸ではと思います。

そうですね

>バックアップ先が今回が初めてのコピーであれば、

>たとえば、src側に.fc_verify_errファイルが存在していた、といったことはありませんか？

あり得ます

>また、fastcopy.log は消さない限り追記されていきますので、

>10/25～10/29の間でベリファイエラーの記録が残っていないかご確認ください。

2016/10/19～残っています

いま見ました。再度

ありました

■参考貼付

=================================================

FastCopy(ver3.25) start at 2016/10/25 05:48:18

<Source>  D:\backup20161022\Thunderbird

<DestDir> C:\Users\〇〇\AppData\Roaming\

<Command> 差分（サイズ・日付） (with Verify)

-------------------------------------------------

Verify Error src:a231a59e49063f1096792e3627e44bd606834ba3 dst:80ba3c52671352cffb44c0eda6d4630feb3ee30d in C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\cert8.db and it was renamed.

 Please check later : C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\cert8.db.fc_verify_err▼

Size is changed : C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\compatibility.ini

Verify Error src:13050a44b1ea912a827b37f300980505fdac2eea dst:1b4db5f0ec367a46f11a1eefc397974922583796 in C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\extensions.json and it was renamed.

 Please check later : C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\extensions.json.fc_verify_err▼

Size is changed : C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\pluginreg.dat

Size is changed : C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\Mail\aaa.biglobe.ne.jp\Inbox.msf

TotalRead  = 19,853 MB

TotalWrite = 19,853 MB

TotalFiles = 534 (40)

TotalTime  = 04:47

TransRate  = 69.1 MB/s

FileRate   = 1.86 files/s

VerifyRead = 19,830 MB

VerifyFiles= 529

Result : (ErrFiles : 5 / ErrDirs : 0)▼▼

=================================================

覚えていませんが、、

●このエラーは基本画面に表示したのでしょうか？？

画面ではいつも「Finished」を確認しているので、

エラー表示していれば気づいたと思うのですが、、

見落とししただけでしょうか？？？

←出なかったと思いますが

仮に色付けできるのでしたら

■「赤字」■で表示していただければ助かります！！！

「現象」

<Source>  D:\backup20161022\Thunderbird

↓

<DestDir> C:\Users\〇〇\AppData\Roaming\

のコピーで起きていたようです。。

つまり

D: 例のHDD(東芝 2T MD04ACA200)

↓

C: 例のSSD Samsung 840 EVO

にコピーした時です

「分析」D:\backup20161022\Thunderbird\ 内の　←オリジナルファイル

cert8.db：（SHA-1）src:A231A59E49063F1096792E3627E44BD606834BA3 ←ハッシュ調べたら、ログと一致

↓　C: SSDへコピーしたら

cert8.db：（SHA-1）dst:80ba3c52671352cffb44c0eda6d4630feb3ee30d

↓　不一致▼

Verify Error

↓

リネームのみ　cert8.db.fc_verify_err　へ

↓

「結果」extensions.json.fc_verify_err　も同様

つまり、「C: 例のSSD Samsung 840 EVO」の故障（異常）ですか？？

「理由」

リードした際のsrcのメモリ上の（ログ）ハッシュ値は正しい　←D:オリジナルファイルのハッシュ値と一致するので

↓

書き込んだ際のdstのハッシュ値が合わない

↓

▼書き込み失敗　「C: 例のSSD Samsung 840 EVO」の故障？

>また、ファイルログを取るようにしていれば

>、（異常はもちろん）正常終了した個々のファイルコピー＆ハッシュ値記録も残りますので、

>src側に存在していた.fc_verify_errを通常ファイルとしてコピーしていた、

>といった情報も残っているはずですが、どうでしょうか？

残念ですが、今回は個別ログは取っていませんでした。。

ので削除してしまったC:側オリジナルファイルの情報はないです

今後は取るようにします。。。

「ログ設定」

↓

「ファイルログを記録（Log\日付.log）」を設定して

ちなみにその下の

↓

ACLエラーをログに記録する

副次Streamエラーをログに記録する

も設定したほうが、ベターですね！？

「余談」

幸い

Verify Error　が発生した時使用したD:側オリジナルファイル

<Source>  D:\backup20161022\Thunderbird

は残っていたので、解析できました。。。

ログファイルをみる限り、Verify Error　は１回だけでした。。

同じようなコピーは結構頻繁（月7，8回？）にやっているのですが、、

なぜ、１回だけなのでしょうか？

なぜ、「C: 例のSSD Samsung 840 EVO」で起きたのでしょうか？

「考察」

------------------

Samsung Magician (サムスンのSSD設定解析ツール)

SMART値表示で、CRC Error Count　の値が、

threshold    : 0  

Current Value: 67  

Worst Value  : 67 

Raw Data     : 33255 ←異常？

Status       : OK

------------------

Raw Data     : 33255 ←異常？

と思っていますが、、メーカは「OK」と言っています

●（１年前にサムスンへ送ってチェックしてもらったら

「異常なし」で帰ってきました。。。）

それでいつも不明です。。？

「最後」

▼TotalFiles = 531 (46)　←46フォルダ？と表示しているのは

45の間違いですか？？？

↓

これは自分のフォルダも１つと数えるので

自分　1

自分の配下 45

--------------------

(46)　←46フォルダは正しいですね。。

[asccssac...@gmail.com]

また、気になります

Size is changed : C:\Users\〇〇\AppData\Roaming\Thunderbird\Profiles\aaaaaaaaa.default\compatibility.ini

この

■Size is changed

もエラーなのですか？

サイズがコピー後に変化している（▼エラー）

ですか？

[Hiroaki SHIROUZU]

Thunderbird配下の、DBファイルでベリファイエラー（mmapされたファイルの書き換えでよく発生）、iniファイルやメールボックス(msf)はサイズ変化（通常の書き換えで発生）、等が頻発していますので、ほぼ間違いなく、Thunderbirdを動作させたまま、コピーしたのだと思います。

（これだけの頻度で、ベリファイエラーが出るのはそれ以外には考えづらいです）

ですので、SSD/HDDの信頼性云々は関係ないのではと思います。

P.S エラーが出た場合、Finished が表示されるEDITBOXではなく、その下部にエラー情報用のEDITBOXが出現してそこに表示されます。

[asccssac...@gmail.com]

＞ほぼ間違いなく、Thunderbirdを動作させたまま、コピーしたのだと思います。

＞（これだけの頻度で、ベリファイエラーが出るのはそれ以外には考えづらいです）

恐縮です。。

確認しておきます。。

再現させて。。。

HDD バックアップから

↓

SSD へデータ復活処理です

▲無論「Thunderbird」が動いていない状態ですが、、

データ復活後

↓

「Thunderbird」●インストール　です。。。から

＞ですので、SSD/HDDの信頼性云々は関係ないのではと思います。

それなら助かりますが、、、

>P.S エラーが出た場合、

>Finished が表示されるEDITBOXではなく、

>その下部にエラー情報用のEDITBOXが出現してそこに表示されます。

分かりました

次回はよく見ます。。

有難うございます