Perl 34：rename 成功不代表断电后文件一定还在
上篇的临时文件和 rename 可以将“旧的完整报表”切换成“新的完整报表”。在本机 Linux 同目录写法下，测试中两个协作写进程结束后，目标字节恰好是两个金标中的一个，而不是混合半截。把目标换成目录，rename 失败，旧有效目标仍在。这说明本次测试覆盖了通常运行中的替换边界，不说明断电后的磁盘状态。
close 负责 Perl 层的写出与关闭错误检查；它不等同于对临时文件和所在目录都成功做了 fsync。要论证“断电后仍可恢复”，至少需要文件数据和 rename 所在目录元数据的同步协议，并有支持该协议的文件系统与真实故障注入。这里没有执行系统断电、重启后的校验，也没有实现那套同步协议，断电持久化 NOT_RUN。官方 pod/perlfunc.pod 对 rename 明确说平台行为差异很大，不能把 Linux 上的一次成功推广为通用语义。
图：正常替换与断电恢复的证据边界
1 | |
练习：加一个 sleep(1) 再返回 SAVED，能将程序级替换升级为耐断电保证吗？不能；等待时长不是同步协议。正例、rename 失败反例和真实未测项记录在 examples/perl-language/evidence/32-39.md；参考冻结 Perl 5.38.2 pod/perlfunc.pod 的 rename、pod/perlport.pod。
组合错误路径同样不能用“清理成功”替代“发布成功”。修正后的 Report.pm 先保存主错误，再尝试 unlink 临时文件与关闭锁句柄；只有前面所有发布步骤都成功时，锁关闭失败才成为主错误。这样报告可以同时写出“不能替换报表”和“不能清理临时文件”两类事实，但不会把 cleanup 失败伪装成发布阶段的根因。该边界来自本工程测试与 Perl close/rename 返回值，不涉及断电后目录项持久化。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-12
Perl 原定 E01：单行脚本要能还原成完整脚本
perl -n、perl -p、perl -a 常被写成命令行技巧，但课程验收不能只看屏幕上几行输出。Perl 5.38.2 的 perlrun 说明里，-n 给程序包一层 while (<>) { ... }，不会自动打印；-p 同样包循环，但每轮末尾打印当前 $_；-a 在隐式循环里把 split 结果放进 @F，并且文档明说 -a 会隐含设置 -n，-F 会隐含设置 -a 和 -n。这些开关改变的是解释器包裹源码的方式，不是另一套迷你语言。 累计实验 examples/perl-language/experiments/course-oneliners.pl 先写入三行 TSV，再运行三条单行脚本：-ane 'print if $F[0] eq "INFO"' 过滤 INFO，-pe 's/^WARN/ERROR/' 生成替换后的流，-F'\t' -lane 'print "$F[0]:$F[1]"' 输出字段对。实验还把第一条单行脚本还原成完整脚本：显式 while (<>)、显式 split、条件 prin...
2026-10-06
Perl 28：读到 undef 还不能宣告输入结束
对三行样本执行 import，读完、解析、关闭后输出 IMPORTED\t3\n。但“打开成功”不保证“读取成功”：在本机 Linux，open my $input, '<:raw', '.../fixtures' 对目录可成功，第一次 <$input> 随后返回 undef，$! 是 Is a directory。原来的 while (<$input>) 把这一回当 EOF，甚至可能输出 IMPORTED\t0。这不是解析错误，而是 I/O 错误被错误地翻译为有效空文件。 现在逐次 readline 前清 $!；若返回 undef，先检查 $!，有错误则停止并诊断，只有没有错误才视为 EOF。读完仍检查 close，不能将关闭失败当作成功。针对目录的反例实测 STDOUT 0 字节、STDERR cannot read input: Is a directory\n、退出 2；普通合成文件正例返回 0、STDERR 0 字节。目录的这一行为只在冻结 Linux 环境测过，别的平台不能由此推定。 123456$! = 0;my $bytes = &l...
2026-10-06
Perl E08：解包能复跑，与断电能恢复是两张验收单
交付有两个容易混淆的方向：素材包能否离开工作树解开后复跑，报表目标在故障后能否保持有效。前者由第 00 篇素材目录中的完整包承担，要求工具源码、隔离 Text::CSV、合成输入、金标、RUN.md、VERSIONS.md、证据和测试都进包，并在全新目录实跑 prove -r；第 37 篇的 MakeMaker distribution 则是另一份安装练习。两者不能互相替代。 正常写入路径下，report-file demo.tsv DEST 退出 0，STDOUT SAVED\n，目标是完整金标。反例用 invalid.tsv 重试：状态 2、STDOUT 空、STDERR line 1: invalid record\n，旧金标可再次打开核对。rename 失败时旧产物仍保留；但这些运行是在操作系统正常工作的场景。真断电后的目录项持久性和重启恢复 NOT_RUN，无文件与目录 fsync 协议就不能对硬件掉电给出保证。也没有真实云端安装、其他平台重试证据。 图：制品复跑与断电恢复的不同步骤 123可复跑：发布包 -> 摘要核验 -> 解压 -> prove ...
2026-10-06
Perl 24：让 --help 从工具自身的 POD 解释失败状态
脚本长到有五个子命令后，光给出一串参数名不够。调用者需要知道 UTF-8 输入的四列、空结果状态、服务名规范化和报表是否写文件；如果帮助只说明“按日志统计”，运维程序可能把空查询与解析失败当成一回事。 CLI 在 __END__ 后保留 NAME、SYNOPSIS、DESCRIPTION 三段 POD；--help 由随 Perl 安装的 Pod::Usage 2.03 读取同一文件生成文本。实际运行 perl examples/perl-language/bin/logtool.pl --help：STDOUT 从 NAME 开始并列出 report-csv FILE 与空集的状态 0 等契约，STDERR 空、退出码 0。起初直接要求 verbose 2 时，环境里的 perldoc 命令提示没有安装 perl-doc 包，虽有输出却污染 STDERR；改为 -noperldoc => 1 后用内置解析器生成同一份 POD，不靠关闭警告假装无故障。 反例 --help unexpected 不会静默忽略多余参数：STDOUT 空，累计版本的 STDERR 是 usage...
2026-09-19
分布式系统 04：从网络 KV 到持久化恢复
服务端已经把 x=two 写入文件，并完成同步。返回客户端的连接随即关闭，客户端收到错误。服务进程被终止以后，新的进程应该恢复出什么值？客户端用原来的请求 ID 重试，应该重新写一遍，还是取回上次结果？ 第 01 篇的内存去重在重启后会丢失。本篇把业务修改、请求身份和返回结果放进同一条追加日志，再用真实 HTTP 连接和子进程终止验证恢复行为。第 03 篇 讨论 GFS 写入路径中的多个副本；这里暂时收窄到一台机器上的一个服务进程，把单副本自身必须兑现的承诺讲清楚。 网络接口需要先定义可观察语义 这个 KV 服务提供两类请求。GET /kv?key=x 查询当前值；POST /kv 接收包含 ID、Key、Value 的 JSON，将一个键设为指定字符串。写入返回原请求与全局递增的 Revision。首次成功修改获得一个新 revision，同 ID 同参数重试返回第一次的记录，不推进 revision。 revision 在这里仅是单个日志中的序号。它既不是物理时间，也不是跨节点一致性协议里的任期，更不能当作全局分布式事务版本。GET 返回当前值与存储的全局 revision。...
2026-10-06
Perl 15：查询不到记录，不等于输入无效
Course 合成输入先经 import 变成 accepted/rejected 两份 JSON Lines。查询只读 accepted：不带条件的 query 输出全部四条；--level WARN 只输出 WARN；--min-duration 0 输出 duration 为数字且大于等于 0 的三条，排除 duration_ms:null；--contains '.*' 只匹配消息里真的含有点星两个字符的 ERROR 记录。查询条件为空、查询结果为空、输入无效，是三个不同状态。 examples/perl-language/bin/logtool 的查询路径先用 read_jsonl($input) 校验所有 JSON Lines，再构造 make_filter(%conditions)。level 只能是 INFO/WARN/ERROR；min-duration 必须是无前导零的非负整数；contains 是字面包含，不当作正则。tools/replay.pl --case all 覆盖 query-all、query-zero、literal-pattern、inva...
