妻子的一声抱怨，与跑偏的排查路径
2009 年 4 月，一位 Ubuntu 黑客的妻子在社区抱怨：她每周二都无法从 OpenOffice 打印文件，其他日子却一切正常。这个看似荒诞的「Wife 测试」，不仅在技术社区中形成了强烈的记忆点，更将一个隐藏极深的开源生态地雷引爆。
图：Andreas Zwinkau 的原文博客页面。来源：beza1e1.tuxen.de
在最初的报告里，社区的排查路径完全跑偏了。面对这个犹如都市传说的问题，大家首先怀疑这是 OpenOffice 自身的缺陷，因为「其他应用都能打印」。更有用户给出了开源社区里最典型的暴力解法：执行一条 apt-get purge 彻底卸载 OpenOffice，清理残留文件后再重新安装。
这位用户在周四兴奋地报告问题解决了。然而两周后的周二，他不得不回到论坛承认，重装毫无作用，打印机再次罢工。
这说明当故障触发条件与特定时间或外部环境绑定时，海森堡式（Heisenbug）的偶发成功会严重误导排查方向。 用户在周四重装软件并成功打印，仅仅是因为那天不是周二，而不是因为重装本身修复了任何系统层面的逻辑缺陷。这种伪随机的排障假象，是底层基础组件故障中最致命的迷雾。
消失的空格与致命的「Tue」
这个诡异问题的真正线索，其实早在 9 个月前就埋在了 Ubuntu 的缺陷跟踪系统里，只是当时无人察觉它的威力。
2008 年 7 月 15 日，用户 jgallo 在 Ubuntu Launchpad 提交了 bug #248619。他发现只需在终端执行 echo "1/2 Tue" >> file && file file，系统经典的 file 工具就会将其判定为 Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2。当时无人能解释为什么一个包含「Tue」字样的普通文本文件，会被识别成毫不相干的 Erlang 早期 JAM 虚拟机的编译产物。
图：Ubuntu Launchpad Bug #248619 页面。来源：bugs.launchpad.net
直到 2009 年 4 月，开发者们才将这块拼图与「周二无法打印」联系起来。事故的完整链条极度巧合：OpenOffice 在执行打印任务时，会生成 PostScript 文件交给系统。这个文件头包含了带有创建日期的元数据 %%CreationDate: (Tue MMM D hh:mm:ss ...)。而在 CUPS（Linux 通用打印系统）的管线中，系统会调用 Unix 的 file 工具来判断文件类型，以决定如何过滤和处理这些数据。
file 工具依赖一个包含超过 1600 条规则的 magic 数据库，通过「文件魔数特征」来识别文件。其中识别 Erlang JAM 文件的规则被写成了 4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2。
问题的核心，在于规则中的空格没有被反斜杠（\ ）转义。当解析器读到未转义的空格时，它并没有把这段文字当成一个完整的 28 字符字符串进行匹配，而是只匹配了第 4 字节处的「Tue」三个字符。 后面那串 Jan 22 14:32:44 MET 1991 Erlang JAM file... 全部被错误地当作了这条规则的输出描述。
于是，任何在第 4 字节刚好出现「Tue」的文件，都会被 file 强行判定为 Erlang JAM 文件。周二生成的 PostScript 文件，其日期字段中的「Tue」刚好踩中了这个位置。CUPS 拿到「这不是可打印格式」的判定结果，理所当然地拒绝了这笔打印任务。
魔数、顺序依赖与脆弱的验证链
这个导致系统停摆的缺陷，修复方式却极其简单。Debian 侧的开发者 Adam Buchbinder 提交了补丁，将那行规则改为了正确的转义格式：4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2。随后 Ubuntu 也在多个稳定版中同步 backport 了这个修复。
但这起事件真正值得我们警惕的，是这种通过静态规则串联起来的深层结构性风险。更有戏剧性的是，经过后人考证，这条错误的规则原本直接抄自 2007 年的 Erlang FAQ 文档。文档没有写转义符，错误就顺理成章地沉淀进了系统的底层组件中。
在 file 的 magic 数据库中，规则是按顺序进行线性匹配的。这条带有破坏性的 Erlang 规则恰好排在 PostScript 规则前面，一旦它匹配到「Tue」并宣告成功，验证流程就会直接返回，根本轮不到正确的 PostScript 规则生效。实际上，file 工具当时还存在其他误判，例如将 PostScript 误判为 Haskell 文件、或者将 mp3 误判为 XWD 图像，这些都是在同一批补丁中被集中修复的。
在一个庞大而松散的开源工具链中，这种依赖规则先到先得的串行验证机制，使得下游的复杂系统永远暴露在上游微小失误的射程之内。 只要 magic 数据库继续膨胀，基于纯文本特征扫描的文件识别模式，就永远无法摆脱此类规则撞车带来的误判幽灵。
从 500 英里邮件到长尾技术寓言
近期，这桩旧案在 Lobsters 等技术社区再次翻红并获得高赞。它引发了强烈的共鸣，因为这种「物理常识或日历现实入侵纯粹数字逻辑」的故事，总能精准唤起一线工程师的职业共鸣。
不少人立刻联想到了 2002 年另一个被奉为圭臬的排障故事：「500 英里邮件」。在那个故事里，因为 SCSI 超时参数的设置与光速的巧合，导致一台服务器的电子邮件最远只能传输 500 英里。两者有着惊人的相似性：复杂的流水线中，一个极其微小的缺陷通过多层耦合，最终在物理世界中投射出了看似违反常理的 bug 表现。
没有哪个打印管线真的在运行 Erlang 虚拟机，也没有打印机真的患上了「周二综合征」。在高度封装的现代软件栈里，我们常常预设每一层抽象都是坚不可摧的黑盒，并习惯从最表层的应用去寻找故障原因。但「周二不打印」无情地撕开了这层面纱。
一个缺少转义的空格，潜伏在文档里，溜进文件识别规则库，最后跨越了数个层级，击碎了终端用户的打印任务。当下一场看似荒谬的故障出现时，真正的答案往往不在无脑的 purge 和重装按钮上，而是在那些被我们习以为常的基础设施夹缝里。
参考链接：
- OpenOffice does not print on Tuesdays — Andreas Zwinkau
- Ubuntu Launchpad Bug #248619: file incorrectly labeled as Erlang JAM file
- Lobsters 讨论 (2026-08-28)
- The case of the 500-mile email
