前の記事でdirivファイルの重要性について書いたがファイルのバックアップだけでなくファイルリストの作成時にもちょっとした注意事項がある
更に今回は恐れていたdirivファイルの破損にも遭遇した
cppcryptfsにはファイルリストの機能がなく精々「復号化名(元ファイル名)」→「暗号化名」を出力する機能があるくらい
しかも再帰的に取得してくれないのでドライブ全体で取得したりできないので非常に不便
まあ非公式ならいくらでもファイルリストツールなんてあるのでそれを使えばよいのだけどできれば標準マウント先と暗号化フォルダの両方を一気にリスト化してくれるツールがあれば便利だなと思って例のAIに作成してもらった
標準マウントドライブのリスト化は比較的簡単にできた
ファイル名 サイズ 更新日時が取得できるものが簡単に作れる
ただフォルダ名にファイル数やサイズなんかを取得して一緒にリスト化するのは少し手間どったし何よりサーバー負荷が高く途中でリソース不足のエラーが出てコケやすくなる
(pCloud側の帯域もあるけどrclone単体よりもエラーになりやすい)
まあ今のところリトライするしか無い
暗号化フォルダの方はただリスト化するだけでは物足りず
取得したリストから拡張子が diriv と name のもの(所謂メタデータファイル)を省いてカウントし総ファイル数から引けば実ファイル数になると気づいた
このdirivファイルとnameファイルのカウントがいくらやってもうまくいかず色々試した結果驚愕の事実が判明
まず以下のPWSHスクリプトでdirivとnameファイルを数えてみる
# 指定した拡張子フィルターでファイル数を数えるps1
$dirivCount = 0
$nameCount = 0
Get-ChildItem -Path "Y:\cpp\" -Recurse -File -Force | ForEach-Object {
$name = $_.Name.ToLower()
if ($name -eq "*.diriv") {
$dirivCount++
} elseif ($name -like "gocryptfs.longname.*.name") {
$nameCount++
}
}
Write-Host ".diriv ファイル数: $dirivCount"
Write-Host ".name ファイル数: $nameCount"
結果は
.diriv ファイル数: 0
.name ファイル数: 12
nameファイルは正しく取得できてるのに何故かdirivは取得できないと色々AIと議論した挙げ句
もしかして gocryptfs.diriv という名前そのものが間違えているのではないかと
何を言ってるかわからねーが取り敢えずファイル名を調べるスクリプトを実行
# 真のファイル名を取得するデバッグコード
Get-ChildItem -Path "Y:\cpp\" -Recurse -File -Force | ForEach-Object {
$name = $_.Name.ToLower()
if ($_.Name -like "*diriv*") {
Write-Host "DEBUG: $_.Name / $filename" -ForegroundColor Yellow
}
}
この結果が以下
DEBUG: Y:\cpp\gocryptfs.diriv.Name /
・・・
この結果からわかることは
お前拡張子 .Name じゃねーかよ！
結論：gocryptfs.diriv の真のファイル名は gocryptfs.diriv.Name だった
そらずっと拡張がdirivだと思ってたからフィルターかけてカウントしてたのに引っかからないわけだ
あと
拡張子が表示されないように隠蔽すんなし！
このことからファイル数カウントのフィルターを修正した
フィルターのdirivの後にも *gocryptfs.diriv* のようにワイルドカードを設定
たったのこれだけでdirivファイルの数を正確に数えることができる
ちなみに gocryptfs.diriv.Name でマッチングするとnameファイルのマッチングフィルター条件と被るので飽くまでgocryptfs.dirivの部分が引っかかるよう注意
# ※ファイル名の前後にワイルドカードを付けて部分一致にする
if ($filename -like "*gocryptfs.diriv*") {
$fileCount++
$dirivCount++
$size = $length
$totalSize += $size
$totalFileCount++
# ...
} # *.diriv や *gocryptfs.diriv でマッチングかけてもNG
elseif ($filename -match '^gocryptfs\.longname\..+\.name$') {
...
}
# .nameファイルは頭にgocryptfs.longnameが付く事を明示
# 最終サマリ
$realFileCount = $totalFileCount - ($dirivCount + $nameCount)
# 実ファイル数は総ファイル数からdirivとnameファイル数を引く
出力結果の統計情報が以下
### Summary
### リスティング対象 : Y:\cpp\
### リストラベル名 : pcloudcpp_暗号化ファイル
### フォルダ合計数 : 16
### ファイル合計数 : 52
### 実ファイル数(メタデータ除いた数) : 23※この実ファイル数が標準マウントの総ファイル数と一致しているかが重要
もし違いがあれば何らかの不具合で暗号化ファイルが復号化されていないことを意味する
重要：nameファイルは何らかの不具合で0byteになることがある(つまり破損する)
何故こんな事をしているのかというとnameファイルの不具合で0byteのものが生成されファイルが復号化されなかったことがあるからだ
状況としては一度クラウドストレージの暗号化ルートフォルダにファイルを転送後に標準マウントで復号化ファイルをフォルダ間移動させた際
何らかのIOリソース不足や回線不具合などでうまく移動ができなかったのだろう
ちなみにDirIVフラグ付きでdirivを使用している場合ファイル移動するとその都度nameファイルも新しく生成される様なので
ファイル移動→nameファイルを生成→暗号化名をリネームし再暗号化という流れでかなりサーバーにも負荷をかけているように思う
pCloudなど回線不安定なクラウドはdirivは使用しないほうが良い？
今回の件で思ったのは無理にdirivを使用せず運用したほうが今の環境では良いのではと思う
もちろんリバースマウント不可などのデメリットはあるがそもそもAES256-SIVモードはかなり重くてサーバー負荷も心配なので
トラブル回避のためにもAES256-GCMとDeterministic Names モードで運用すべきだと思った
コメントを残す