一个 cp 引发的编译错误

背景

碰到一个偶现的编译出错问题，如图

报错的信息是

cp: 无法创建普通文件"xxx": 文件已存在

排查原因

看了下 Makefile，这句非常简单，就是 cp ./xxx ../xxx 而已，本身没什么问题。

那再结合上下文出现的打印，一个异常之处就是 Makfeile 被并行重复执行了，猜测是并行导致 cp 操作出错。

只考虑解决问题，那无疑是修改外层 Makefile ，避免此处被并行重复执行，至少这句 cp 不要被并行，就可以解决了。

但为什么 cp 并行执行会出错呢？如果在另外的场景下确实有并行执行cp的可能，有没有办法规避这个错误呢？这就得探究下了。

单独执行 cp，默认的行为就是覆盖已存在的文件，并不会因为 “文件已存在” 这样的原因出错，随便做下实验，touch a b; cp a b就可以确认正常是不会报错的。

那问题还是得结合并行来分析，碰到这种情况，要么是从搜索资料获得提示，要么就是实践出真知，自己设计一个可快速复现的方式，然后使用调试工具来追踪问题发生时的具体情况。

具体到这个问题，我是搜索到相同的stackexchange^[1]问题，那就省点工夫不用自己去复现分析了。

这里插下题外话，搜索优先使用google，对于中文报错信息查不到的可改成英文查询。例如中文的 cp: 无法创建普通文件 文件已存在 就不好找到答案，换成 cp cannot create regular file file exists 就好找了（只敲一部分，搜索引擎就能提示完整的信息）。

stackexchage上给出了一个脚本，用于复现问题并使用 strace 将追踪的系统调用记录下来。

#!/bin/bash

touch a

f() {
  while true; do
    rm -f b
    strace -o /tmp/cp${BASHPID}.trace cp a b || break
  done
}

cleanup() {
  kill -9 %1 %2
}

f &
f &

trap cleanup exit

wait

附上我自己的实验结果，可以看出cp的实现上，会先用stat来判断目标文件b是否存在，如果不存在则会使用 open("b", O_WRONLY|O_CREAT|O_EXCL, 0664) 来创建目标文件并将源文件写入目标文件，完成复制。

那么如果两个 cp 并发，就可能出现

cp1                  cp2
stat判断b不存在
                     stat判断b不存在
open成功，创建文件b
                     open失败，因为此时文件已经被cp1创建好了

从 strace 的 log 看到的就是

由于 cp 不是原子的，如果两个 cp 刚好几乎同时执行，则可能两个 cp 的stat都判断到文件不存在，那最终只有一个 cp 能创建文件，另一个就失败了。

顺便看看，文件存在和不存在的open参数差异

解决办法

既然两个cp同时执行会出错，那就加锁呗。

如果所有调用 cp 的地方都是我们可控的，那劝告锁就足够了，在 shell 中可以直接使用 flock。

约定好一个文件锁x, 将原来的cp a b 改成 flock x cp a b 即可。

例如正常在两个控制台中，执行top是可以并行的，但如果改成执行 flock /tmp/toplock top，那就只有控制台1会执行top，控制台2则处于等待文件锁的状态。此时若控制台1退出top，则控制台2获得锁，开始执行top。

更多文件锁的细节，可以看看 man flock。今天顺便试试专辑功能，入口在最上方 ↑

参考资料