Unix/Linux下读写Python进程共用文件时，调用truncate是否安全？

直接给结论：不安全，会导致写入进程行为不符合预期，还会破坏你的缓冲区处理逻辑。

为什么直接truncate会出问题？ #

Unix/Linux文件系统采用inode与文件描述符分离的设计：

• 写入进程持有独立的文件描述符，里面记录着当前的写入偏移量（比如已经写到文件第1000字节的位置）。
• 读取进程调用truncate()（不管是Python的os.truncate还是文件对象的truncate方法），仅修改文件inode记录的文件大小（比如改成0），但写入进程的文件描述符里的偏移量不会被重置。

这会引发两个核心问题：

1. 稀疏文件产生：写入进程下次写入时，会从之前的偏移量（比如1000）开始写，直接让文件大小跳到「偏移量+写入字节数」，中间0-999的部分会变成“空洞”（磁盘上不实际占用空间，但文件大小显示很大），完全达不到你“防止文件过大”的目的。
2. 读取逻辑混乱：读取进程截断后从头读，会先读到空洞的0字节，之后才会读到写入进程新写的内容，直接打乱数据处理流程。

对写入进程有什么影响？ #

写入进程不会崩溃——Unix系统允许这种“超出文件当前大小”的写入操作，但写入的内容会出现在文件的偏移量位置而非开头，导致文件结构异常，后续写入的内容无法被读取进程按预期捕获。

正确的处理方式 #

要安全控制缓冲区文件大小，推荐两种方案：

• 日志轮换：当文件达到阈值时，通知写入进程切换到新文件（比如给写入进程发SIGUSR1信号，让它关闭旧文件、打开新文件），读取进程处理完旧文件后即可安全删除或截断它。这是日志系统的标准做法，能彻底避免进程间操作冲突。
• 文件锁同步：用Python的fcntl模块调用flock，在写入和截断操作前加独占锁。比如写入进程每次写入前获取锁，读取进程截断前也获取锁，确保同一时间只有一个进程操作文件。注意：如果写入进程是通过stdout重定向到文件的（比如python writer.py > buffer.txt），需要修改写入进程代码，把sys.stdout替换成带锁的文件对象，默认的stdout写入不会主动加锁。

内容的提问来源于stack exchange，提问作者augray