FreeBSD環境で更新日が1970年1月1日になったNextcloudのファイルを直す

数年前のある日、突然Nextcloudのクライアントが「ファイルの更新日時が不正」というエラーを吐いてファイルの同期ができなくなった。確認してみると、大量のファイルの更新日時(mtime)が1970年1月1日になってるやんけえええええええ！！！！

どこをどうみてもUNIXエポックです、本当にありがとうございました。デスクトップクライアントv3.4.0でのやらかしらしい？

同期を再開させるだけなら、touchでmtimeを現在日時に更新してやればよい。でもワタクシはファイル探すときに結構mtime使うんですよね、なので極力元に戻したい。幸い、作成日時(ctime)とアクセス日時(atime)のいずれかは無事なようなので、それらからmtimeの復元を試みる。公式でmtime correction tool kitという、名前のとおりの復旧ツールが用意されているが、こちらはLinux環境向けでFreeBSDでそのまま使うことはできない¹⁾ので、これらを参考に手動で直す。

まずは、mtimeが1970/1/1になったファイルを抽出する。Nextcloudのデータフォルダは/mnt/nextcloud/dataとする。

findで「mtimeがUNIX時間の0である」と指定する方法がわからなかったので、「mtimeが40年前（2024年9月時点で1984年9月）より新しい」とした。単位は分であることに注意。で、該当するファイルの作成日時(birthtime)、作成日時(ctime)、更新日時(mtime), 最終アクセス日時(atime), ファイル名をファイルに書き出す。

# cd /mnt/nextcloud/data
# find . -mmin +21024000 -print0 | xargs -0 stat -f "%SB,%Sc,%Sm,%Sa,\"%N\"" -t "%s" > /tmp/epoch_time_file_list.csv

CSVをExcelで開き、諸々整形する。UNIX時間→Excel日時の変換数式は=(UNIX時間のセル+32400)/86400+25569で、セル書式をyyyy/mm/dd hh:mm:ssとすればよい。

とりあえず、各種タイムスタンプの中で最も新しい値をmtimeとして採用することにした。どうもNextcloudに突っ込んだ時点でmtime以外の情報は消失しているような気がする²⁾ので、こんなに頑張っても仕方ないと思いつつ、現在日時にするのはなんか嫌なので。

Excelからタイムスタンプ,ファイルパスのCSVを書き出し、以下のようなスクリプトに食わせればmtime, atimeがそれなりに復旧できる。

#!/usr/local/bin/bash

while IFS=, read datetime file
do
    touch -t $datetime "$file"
done < $1

それにしてもだなー、Nextcloudがmtimeしか保持してないっぽいのは結構衝撃。デバイス間の同期が楽で、意識することなく履歴付きバックアップにもなるなーと思って建てたけど、自分の用途には合わないかなぁ…便利なんだけどさー。zipなんかも更新日時しか保持しないし、アクセス日時はともかく、みんな作成日時とか気にしないのかしら…？

他のクラウドストレージはどうなんだろう、と気になってたらDropboxとGoogle Driveを調べてる方がいた。子曰く、どちらも基本的に同期クライアントを使った場合は更新日時は保持されるとのこと。デスヨネー。

結局、ファイル属性含めて保持しておきたいなら、ローカルストレージかSMBでせっせとバックアップするしかないのかねぇ。理想の形はMacのTimeMachine。設定したら知らぬ間にバックアップがとられてて、イザって時に大助かりというやつ。WindowsもVSS（復元ポイント）で似たようなことはできるが、如何せんUIがダメダメすぎる。TimeMachine並にイケててリッチにしろとは言わないが、ファイル/フォルダのプロパティに押し込まれててアクセス性が最悪すぎる。

かといってOneDriveは仕様が素晴らしすぎて全く使う気になれないし。

Windowsのバックアップソリューション、もっとなんとかならんものか。