数年前のある日、突然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のバックアップソリューション、もっとなんとかならんものか。

• Desktop client 3.4.0 destroys local time stamp and keeps uploading data to server - 📱 Desktop & mobile clients - Nextcloud community
• GitHub - nextcloud-gmbh/mtime_fixer_tool_kit: Tool kit to fix the mtime issue on the server state
• 多分すごく分かり易い！UNIXTIMEをエクセルで扱う方法 - まるノート
• 【備忘録】ファイルの更新日時を維持したまま、オンラインストレージに預けたり取り出したりしたい！｜犬川さと

もはや旧聞に属する話だが、2023年11月9日のRAID-Z Expansionのプルリクがついにmasterにマージされていた。コンセプトが発表されてから足掛け7年、実に長かった。なかなかインパクトのある機能だし仕方ないか。関係者の皆様お疲れ様でございました。

とはいったものの、実際にリリースされて使えるようになるのは、まだ先と思われる。リリース時期に関する最新情報は見つけられなかったのだけど、2021年時点のロードマップではOpenZFS 3.0で対応予定となっている。どんなに早くても2.3かなー？と思いつつ、どちらのバージョンのブランチもまだ存在しないのが現状。

加えてFreeBSDで使うには、ベースシステムに取り込まれるのを待たなきゃならんわけで、1年以上先なんじゃね？という気がしなくもない（まぁportsから入れればいいんだけども）。首を長くして待ちましょー

ついでにプルリク一覧を眺めていたら、ファイル名/ディレクトリ名の最大長を1023バイトに拡張する新しい機能フラグの実装があった⇒Longname: files/directories name upto 1023 bytes by tuxoko · Pull Request #15921 · openzfs/zfs

ZFSのファイル名/ディレクトリ名の最大長は255バイトとされているが、これはFILE_MAXだかPATH_MAX定数由来の制約らしい。これはUNIX系のファイルシステムにおける典型的な最大長で、通常はほとんど困らないサイズである。

ところが、ファイル名の文字コードとしてUTF-8を使うと話が変わってくる。UTF-8では1文字あたりのバイト数が1～4バイトと可変なので、ワーストケースで63文字しか格納できない。日本語の文字種はおおむね3バイトになるため、85文字で打ち止めとなる。

これでもFreeBSD、Linux単体で使う分にはさほど問題にならないと思うが、Windowsとファイル共有するとだいぶ困ったことになる。 というのもWindows (NTFS)の最大長はUTF-16で255文字³⁾なので、ZFSの255バイトでは全然足りんのです。 まぁ、日常的に85文字を超えるファイル名を使うことは、少なくとも自分は無いけれど、それでも1年に2～3回くらいは困る場面があるんだよね…

上記PRとは別に(?)最大長拡張の議論もなされており、開発のコアメンバーも認識はしている模様。互換性はどうなるんだとか、最大255文字で決め打ちしてるアプリで扱おうとした時にどうなるんだとか、色々気になる点はあるが、是非とも実現されてほしいところ。

• Longname: files/directories name upto 1023 bytes by tuxoko · Pull Request #15921 · openzfs/zfs
• Allow maximum file name length to be increased · Issue #13043 · openzfs/zfs

Ctrl+Del+Altからのパスワード変更画面で、ユーザー名をリモートコンピュータ名\ユーザー名とすると、ローカルPCアカウントと同じ要領でリモートPCのローカルアカウント（ややこしい）のパスワードを変えられるそうなんだけど、最近のWindowsでは以下のおまじないが必要だそう。

1. コマンドプロンプトで以下のコマンドを実行（レジストリ追加）
   • REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters /v NullSessionPipes /t REG_MULTI_SZ /d SAMR /f
   • REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RestrictRemoteSamAuditOnlyMode /t REG_DWORD /d 1 /f
2. Windowsファイアウォールで「Netlogonサービス」を許可

ファイヤウォールの穴あけまで言及してるサイトが殆どなくて結構ハマった。

• 山市良のえぬなんとかわーるど: 覚書：リモートからサーバーのローカルユーザーのパスワード変更（ワークグループ、Windows Server 2016 以降）
• リモトでサバのパスワド更 - 役に立つ…かもしれないパソコン日記

僕はついさっき知ったばかりなんですけど、C#の数値0ってあらゆるenum値に暗黙的キャストされるんですってね。要するに、0だけはキャスト不要で列挙型の値として変数に代入できちゃったりするということ。コードで示すと以下のようなかんじ。

using System;
 
public class Program
{
    enum Hoge { A, B }
    enum Piyo { C, D }
 
    public static void Main()
    {
        Hoge h1 = 0,   h2 = 0.0f;
        Piyo p1 = 0x0, p2 = 0.0m;
        Console.WriteLine($"{h1}, {h2}");
        Console.WriteLine($"{p1}, {p2}");
    }
}

このコードは何の警告もなくビルドが通り、以下の実行結果が得られる。

A, A
C, C

浮動小数点数やDecimalのゼロも同様の扱いっていうのが、なかなかのキモいポイント。C#のenumってC/C++のそれと違ってそれなりに厳密なので、自分的には結構衝撃的な仕様だった。まぁ、分かってしまえばどうってことはない。

で、ここからが本題。

そんな0のenumへの暗黙的型変換のおかげで、意図せぬメソッドのオーバーロード解決が行われ、小一時間ハマった。

以下のような処理メソッドAddと、それに対する単体テストAddTestを考える。対象メソッドはプライベートな静的メソッドなので、テスト呼び出しにはPrivateType.InvokeStaticメソッドを使っているが、至ってシンプルなコードである。

何の疑いもなく動くと思いきや、ケース3のテストでのみMissingMethodException例外が発生し、Addメソッドの呼び出しに失敗するのだ！

// 加算
private static decimal? Add(decimal? v1, decimal? v2)
{
    return v1 + v2;
}
 
// Addメソッドの単体テスト
void AddTest()
{
    var privateType = new PrivateType(typeof(AddClass));
 
    // ケース1
    var value = (decimal?)privateType.InvokeStatic("Add", 1.0m, 1.0m); // OK
    Assert.AreEqual(2, value);
 
    // ケース2    
    value = (decimal?)privateType.InvokeStatic("Add", 1.0m, 0.0m); // OK
    Assert.AreEqual(1, value);
 
    // ケース3
    value = (decimal?)privateType.InvokeStatic("Add", 0.0m, 1.0m); // MissingMethodException例外が発生！
    Assert.AreEqual(1, value);
}

MissingMethodExceptionは読んで字のごとく、メソッドが見つからなかった場合に投げられる例外だ。

ケース1～2は通っているのに見つからないとは一体…!?という感じなのだが、これまでの説明からお気づきであろう、ケース1～2と3では呼び出されるInvokeStaticのシグネチャが違うのだ。同メソッドは引数違いで10個ほどのオーバーロードが定義されており、それぞれ以下のシグネチャのものが呼び出される。

• ケース1～2
  • InvokeStatic(String, params Object[])
• ケース3
  • InvokeStatic(string, System.Reflection.BindingFlags, params Object[])

ケース3では、第二引数の0.0mがBindingFlagsに暗黙キャストされた結果、引数を1つ持つAddメソッドを呼び出そうとして例外を吐くというわけ。なんじゃそりゃー！分かるわけネェーッ！！意図通り動かすにはprivateType.InvokeStatic(“Add”, (decimal?)0.0m, 1.0m)のように、明示的にキャストし正しいオーバーロード解決を導いてあげればよい。

この暗黙型変換を禁止ないし警告出してくれるコンパイルオプションとかないのかしら…ハマった時に死ぬほどわかりづらいんですけど……

PowerEdge T330とITファームを書き込んでHBA化したPERC H330環境で、H330に接続したストレージにインストールしたProxmox VE 8.0-2を起動しようとすると、EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device pathと出て止まってしまう。マザボから生えてる内蔵SATAの方だと問題ない。

PVEのフォーラムでも同様の現象が報告されている。

• Stuck at EFI stub | Proxmox Support Forum
• Proxmox 8 boot stuck at "EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path" | Proxmox Support Forum

ZFSがらみの何かっぽくext4なら大丈夫らしい。根本的な解決策は見当たらないが、PVE 7をインストールしアップデートでPVE 8にした場合は起動するそうで、試しにやってみたら確かに問題なくPVE 8が立ち上がった。すんごい気持ち悪いんですけど。

BIOSとiDRACあたりとの相性かと思い数時間かけて頑張って更新したが、完全な無駄足になってしまった…。更新後はJava版の仮想コンソールが何故か起動に失敗すること多いし、PVEで仮想コンソールのキー入力が全く効かないわ、ACPIシャットダウンが機能しないわでマジで意味がわからん。ただの無駄足であってくれた方がなんと良かったことか……

一応PVEの動作に問題はなさそうだけど、どうしたものか。