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

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

どこをどうみてもUNIXエポックです、本当にありがとうございました。[[https://help.nextcloud.com/t/desktop-client-3-4-0-destroys-local-time-stamp-and-keeps-uploading-data-to-server/128512|デスクトップクライアントv3.4.0でのやらかしらしい？]]

同期を再開させるだけなら、touchでmtimeを現在日時に更新してやればよい。でもワタクシはファイル探すときに結構mtime使うんですよね、なので極力元に戻したい。幸い、作成日時(ctime)とアクセス日時(atime)のいずれかは無事なようなので、それらからmtimeの復元を試みる。公式で[[https://github.com/nextcloud-gmbh/mtime_fixer_tool_kit|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), ファイル名をファイルに書き出す。

<code>
# 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
</code>

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

{{ :blog:2024:nextcloud_list_up_unix_epoch_files.png |}}

とりあえず、各種タイムスタンプの中で最も新しい値をmtimeとして採用することにした。どうもNextcloudに突っ込んだ時点でmtime以外の情報は消失しているような気がする((DB上はmtime, mtime_storageというフィールドしかない。初回アップロードを行ったオリジナルのローカルファイルが無くなると、ctime等は失われると思われる。))ので、こんなに頑張っても仕方ないと思いつつ、現在日時にするのはなんか嫌なので。

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

<code>
#!/usr/local/bin/bash

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

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

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

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

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

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

===== 参考サイト =====

  * [[https://help.nextcloud.com/t/desktop-client-3-4-0-destroys-local-time-stamp-and-keeps-uploading-data-to-server/128512|Desktop client 3.4.0 destroys local time stamp and keeps uploading data to server - 📱 Desktop & mobile clients - Nextcloud community]]
  * [[https://github.com/nextcloud-gmbh/mtime_fixer_tool_kit|GitHub - nextcloud-gmbh/mtime_fixer_tool_kit: Tool kit to fix the mtime issue on the server state]]
  * [[https://maru-note.net/entry/2023/08/24/221551|多分すごく分かり易い！UNIXTIMEをエクセルで扱う方法 - まるノート]]
  * [[https://note.com/sato_inukawa/n/n3d543e4743ef|【備忘録】ファイルの更新日時を維持したまま、オンラインストレージに預けたり取り出したりしたい！｜犬川さと]]