做Linux开发这些年我越来越觉得open、read、write、close这组文件IO函数是最难啃但最该啃的基础功。我刚上班那阵子带我的前辈让我实现一个文件复制工具我第一反应是去查fopen文档写完交差了事。后来他问了一句“你用的fopen底层到底干了什么”我当场愣住。从那以后我才把这四个系统调用翻来覆去捋透也是从那时候起很多以前觉得“玄学”的读写问题突然都能看懂了。今天这篇就围绕这四个函数展开文件描述符是什么open为什么返回一个整数read和write的返回值到底藏着哪些信息以及怎么用它们手工完成一次文件复制。无论你是刚入门Linux编程还是准备面试想补IO基础或者总被莫名其妙的读写问题坑过都建议完整看一遍——这些内容看起来基础实际里面藏着不少容易翻车的细节。1. 为什么文件IO是Linux开发绕不开的基本功1.1 一切皆文件同一套IO心智模型适用所有场景“一切皆文件”在Linux里不是口号。普通磁盘文件、目录、管道、socket、字符设备、块设备甚至终端输入输出最终都抽象成文件描述符通过同一套open/read/write/close接口来操作。这意味着什么呢你学会了操作普通文件后面学socket编程、管道通信、设备驱动心智模型基本是平移的。比如网络socket有专门的send/recv接口但它在底层仍然依赖fd机制配合epoll、select监听时处理的照样是文件描述符命令管道pipe返回的两个fd本质也是文件描述符你往终端输出日志时用的fd就是系统默认分配好的标准输出。所以文件IO不是孤立知识点它是整个Linux系统编程的地基。很多人觉得网络编程难、高并发难追根溯源卡住的往往是“fd的状态转换”“缓冲区里到底有没有数据”“write没写完怎么处理”这类IO基本功。1.2 为什么先啃系统调用而不是直接用标准库日常写业务代码用fopen、fread、fwrite确实舒服C标准库帮你做了用户态缓冲接口更友好。但问题在于标准库把底层细节藏得太深一旦出问题你根本不知道它在背后做了什么。举个例子如果你混用read和fread操作同一个文件描述符大概率会读到奇怪的数据因为fread内部会把多余的数据吞进自己的缓冲区而read直接走内核两边数据不一致。再比如你想用O_DIRECT绕过页缓存做直IO标准库根本控制不了这个粒度处理非阻塞socket时EAGAIN这类errno是系统调用级别才存在的语义标准库接口包装之后很容易让你忽略真实错误码。我建议的学习路径是先用系统调用亲手搭一遍IO流程理解read/write的真实语义再去享受标准库的便利。面试也经常问“read的返回值有哪些含义”“为什么write要循环”这些问题不亲手写过真答不到点上。2. open与close文件描述符Linux世界里最值钱的整数2.1 open函数的两个签名以及flags和mode的细节open有两个常用签名#include sys/types.h #include sys/stat.h #include fcntl.h int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode);第二个签名多了一个mode参数只有在flags里带上O_CREAT时这个参数才会被用到。内核通过变长参数机制获取第三个参数如果没传就读取一个不确定的值所以该传的时候千万别漏否则创建出来的文件权限会很诡异。flags参数是这个函数的核心需要掌握的几类flags作用备注O_RDONLY只读打开值等于0O_WRONLY只写打开值等于1O_RDWR读写打开值等于2O_CREAT文件不存在则创建需要配合mode参数O_EXCL与O_CREAT连用文件已存在则失败防止覆盖的利器O_TRUNC打开同时把文件长度截断为0危险慎用O_APPEND每次写入追加到文件末尾对日志文件很关键mode是创建文件时的请求权限通常传0644或者0666。但它不是最终权限实际权限等于mode ~umask。比如系统umask是022你请求0666实际创建出来是0644因为组和其他用户的写权限被umask剥掉了。这个细节经常让新人困惑以为是open写错了。open失败时返回-1并设置errno。用perror或者strerror(errno)能直接看到原因比如ENOENT表示文件不存在EACCES表示权限不够EISDIR表示你试图用写方式打开一个目录。调试时养成先看errno的习惯比瞎猜快得多。2.2 返回值到底代表什么文件描述符的分配规则open成功返回一个非负整数这就是文件描述符。它本质上是进程文件描述符表的下标指向内核维护的打开文件描述。理解了这一点很多规则就顺理成章了。进程启动时0、1、2已经被占用分别对应标准输入、标准输出、标准错误。所以普通的open返回的第一个fd通常是3。内核分配fd的规则是从小到大找第一个空闲位置所以你连续open两个文件大概率得到3和4。如果先把fd 0关闭再open新的fd就可能是0shell的重定向机制利用的正是这个规则。文件描述符是一种进程级资源有数量上限。用ulimit -n可以查看传统默认是1024很多高并发服务会调大到65535甚至更高。如果一个进程只open不closefd数量越涨越高最终报Too many open files这就是典型的文件描述符泄漏。2.3 close和文件描述符泄漏一个常被忽略的资源管理问题close函数很简单作用就是把fd关掉让这个fd重新回到可分配状态。#include unistd.h int close(int fd);但简单归简单有几个习惯值得养成。第一打开文件后无论后续成功还是失败都要保证close被执行。我见过不少代码在错误分支里直接returnfd就这么泄漏了。第二不要重复close同一个fd。fd被关闭后可能被后续open复用你再close一次可能就把别人正在用的fd给关了这种bug极其隐蔽。第三close是“关闭fd”不保证数据立刻落到磁盘内核会按策略刷盘想强制落盘需要fsync。我把fd当成“借来的资源”——尽早打开用完马上还谁借谁还。尤其写长生命周期的服务时fd泄漏是慢刀割肉撑到某天突然全线报错排查起来非常痛苦。3. read与write别指望一次把文件读完3.1 read的返回值每次读到多少内核说了算read的原型长这样#include unistd.h ssize_t read(int fd, void *buf, size_t count);第一个参数是fd第二个参数是存放数据的缓冲区第三个是请求读取的最大字节数。返回值是重点返回值含义正数实际读到的字节数可能小于count0到达文件末尾EOF-1出错具体原因看errno新手最容易踩的误区是我请求读4096字节read就一定会返回4096。对于普通磁盘文件如果剩余数据足够通常确实会读满4096但如果文件只剩100字节read就只返回100面对管道、终端、socket这类特殊fd哪怕缓冲区还有大量数据内核也可能只给你一小部分具体返回多少由内核调度决定完全不可控。所以正确理解是这样的read的count是“最多读多少”不是“必须读多少”。想要安全地读完所有数据必须循环调用read直到返回0或者-1。这就是文件复制程序需要循环读的根本原因。3.2 write并不保证一次写完循环写入的必要性write的原型和read类似ssize_t write(int fd, const void *buf, size_t count);它返回实际写入的字节数。常规磁盘文件场景下write一般能一次写完count字节但这不是语言规范给你的保证。在socket或管道场景如果对端缓冲区不足write只会写入一部分甚至只写进去1个字节返回值就是那个部分字节数。一个严谨的写入逻辑必须这样处理记录已经写入的字节数如果write返回值小于剩余字节数就从buf的偏移位置继续写直到全部写完。这个“循环写”模式在网络编程里是保命代码很多初学者写的socket收发程序丢数据根因就是只调用了一次write没处理partial write。3.3 EINTR与EAGAIN信号和非阻塞带来的额外维度read和write返回-1时并不是所有错误都该直接退出。有两个errno需要特别认识。EINTR表示系统调用被信号打断。比如程序有一个定时器信号频繁触发read在等待数据时被打断内核就会返回-1并设置EINTR。这种错误不是致命的正确做法是重试这次调用。EAGAIN表示在非阻塞模式下当前没有数据可读或缓冲区已满不是错误而是“现在没条件你可以干别的事待会儿再试”。这在epoll模型里极其常见处理非阻塞socket时几乎天天见到。理解了这两个值你就能看懂很多生产级代码里为什么会有if (errno EINTR) continue;这种写法。4. 手写文件复制从需求到代码到跑通的完整过程4.1 需求拆解与设计决策缓冲区、打开方式和错误策略文件复制的需求很朴素给定源文件路径和目标文件路径把源文件内容逐个字节搬运到目标文件里。设计上有几个点要提前想清楚。一是缓冲区大小。这次取4096字节正好是一页大小也是实际项目里很常用的选择后面会专门分析性能和缓冲区的关系。二是打开方式。源文件用O_RDONLY只读打开目标文件用O_WRONLY | O_CREAT | O_TRUNC不存在就创建存在就截断重写。三是错误策略哪个环节失败都要有明确交代该关的fd必须关。顺便说一句复制过程不需要手动管理文件的进度内核为每个fd维护了独立的文件偏移量每read或write一次偏移量自动往后推这是系统给我们免费提供的便利。4.2 完整代码一个能跑且足够严谨的复制程序#include stdio.h #include stdlib.h #include unistd.h #include fcntl.h #include errno.h #define BUFFER_SIZE 4096 int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, Usage: %s source dest\n, argv[0]); exit(EXIT_FAILURE); } int src_fd open(argv[1], O_RDONLY); if (src_fd 0) { perror(open source); exit(EXIT_FAILURE); } int dst_fd open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0644); if (dst_fd 0) { perror(open dest); close(src_fd); exit(EXIT_FAILURE); } char buf[BUFFER_SIZE]; ssize_t nread; for (;;) { nread read(src_fd, buf, sizeof(buf)); if (nread 0) { if (errno EINTR) continue; perror(read); close(src_fd); close(dst_fd); return EXIT_FAILURE; } if (nread 0) break; /* EOF */ ssize_t written 0; while (written nread) { ssize_t nwrite write(dst_fd, buf written, nread - written); if (nwrite 0) { if (errno EINTR) continue; perror(write); close(src_fd); close(dst_fd); return EXIT_FAILURE; } written nwrite; } } close(src_fd); close(dst_fd); return 0; }外层的for循环解决“一次读不完”的问题一直读到返回0才认为到达文件末尾。内层while解决“一次写不完”的问题每次从buf的偏移位置继续写。遇到EINTR就continue重试遇到真正的错误就打印原因并回收fd。这段代码覆盖了前面讲的全部核心语义。提示代码里对read和write的EINTR都做了重试。对磁盘文件这种情况很少遇到但放到网络环境下就是必须的处理逻辑。保持这个习惯代码的健壮性会上一个台阶。4.3 编译、运行与验证用事实说话编译不需要链接额外库gcc -Wall -O2 filecopy.c -o filecopy准备一个测试文件运行echo hello file io test.txt ./filecopy test.txt copy.txt diff test.txt copy.txt echo OKdiff没有任何输出并打印OK说明两个文件内容一致。也可以顺便用md5sum校验md5sum test.txt copy.txt再试试异常场景。源文件不存在时程序会输出open source: No such file or directory。目标目录没有写权限时会输出open dest: Permission denied。目标文件原本有内容时由于O_TRUNC的存在它会被清空重写这一点在复制时要心里有数。注意想观察系统调用的真实过程可以跑一遍strace ./filecopy test.txt copy.txt你能亲眼看到open、read、write、close按顺序出现这比任何解释都直观。5. 复制性能实测与踩坑记录缓冲区大小、截断和偏移量的教训5.1 同样的代码为什么缓冲区大小不同性能差几倍每次read和write都是一次用户态到内核态的切换调用次数直接决定系统调用开销。假设文件大小是1GB用不同缓冲区大小系统调用次数差距非常直观缓冲区大小read调用次数write调用次数512字节约200万次约200万次4KB约25万次约25万次64KB约1.6万次约1.6万次1MB约1000次约1000次从512字节到64KB系统调用次数减少了128倍实测耗时会看到非常明显的变化尤其是在传统机械硬盘上。这也是为什么copy工具普遍默认使用较大缓冲区的原因。但缓冲区也不是越大越好单次请求过大时如果内核页缓存无法一次性满足反而可能在内核内部拆分处理用户态缓冲区太大会占用内存得不偿失。实践下来4KB起步64KB到1MB之间通常是比较理性的区间。给读者留个实验修改BUFFER_SIZE分别取512、4096、65536编译后用/usr/bin/time -v ./filecopy 大文件 目标文件对比输出你会对“系统调用是成本”这句话有切身体会。5.2 偏移量、截断与权限复制代码最容易翻车的三个隐蔽坑第一个坑是偏移量的误解。fd的偏移量在内核里是自动前进的这也是复制程序能正常跑完的原因。但有人会疑惑“为什么读完一遍之后再用同一个fd读不到任何数据”——不是文件被删了而是偏移量已经在文件末尾。想重新读就得close重新open或者用lseek把偏移量拨回去。第二个坑是O_TRUNC误用。现实中把源文件当成目标文件打开、顺手加O_TRUNC导致源文件被清空的事故并不少见。一旦open的fd指向源文件本身O_TRUNC会在你读取数据之前就把文件截成0字节复制出来的只能是一个空文件。如果目标是创建备份建议无论如何都先以只读方式验证源文件可打开再打开目标文件。第三个坑是权限和umask。前面说过open传0666实际权限可能变成0644。复制工具如果希望目标文件权限和源文件一致不能依赖mode参数需要在open之后再显式做权限调整。这些细节平时不会暴露但一旦需要精确控制文件权限就会被坑得很惨。5.3 从四个函数走向工程化标准库、零拷贝与更复杂的IO写业务代码追求效率时直接用标准库fopen/fread/fwrite是合理的它们内部封装的缓冲机制已经能处理大部分场景。但标准库解决不了的问题是零拷贝。sendfile系统调用允许内核直接把一个fd的数据拷贝到另一个fd完全不经用户态缓冲区复制大文件时的性能优势明显mmap加memcpy是另一条路适合需要随机访问文件的场景再往上的io_uring可以直接提交一批IO请求减少系统调用次数和上下文切换。但无论这些高级IO方案怎么变基本语义仍绕不开本文讲的东西fd代表什么read返回0是EOFwrite可能部分写入EINTR表示可以重试。遇到疑难问题时最终都要回到这四个函数建立的地基上思考问题。按我个人习惯复制小文件或写工具脚本直接cp或标准库就完事但排查性能问题、处理特殊设备、调试并发写入时我一定是回到open/read/write/close这套系统调用上想问题。建议你把这个复制程序改一改缓冲区大小跑一次time再盯着strace输出看几遍调用序列对Linux IO模型会有完全不一样的感觉。后面我还打算写一篇关于lseek偏移量、O_APPEND追加写和零拷贝进阶的内容到时候再聊。
做Linux开发这些年我越来越觉得open、read、write、close这组文件IO函数是最难啃但最该啃的基础功。我刚上班那阵子带我的前辈让我实现一个文件复制工具我第一反应是去查fopen文档写完交差了事。后来他问了一句“你用的fopen底层到底干了什么”我当场愣住。从那以后我才把这四个系统调用翻来覆去捋透也是从那时候起很多以前觉得“玄学”的读写问题突然都能看懂了。今天这篇就围绕这四个函数展开文件描述符是什么open为什么返回一个整数read和write的返回值到底藏着哪些信息以及怎么用它们手工完成一次文件复制。无论你是刚入门Linux编程还是准备面试想补IO基础或者总被莫名其妙的读写问题坑过都建议完整看一遍——这些内容看起来基础实际里面藏着不少容易翻车的细节。1. 为什么文件IO是Linux开发绕不开的基本功1.1 一切皆文件同一套IO心智模型适用所有场景“一切皆文件”在Linux里不是口号。普通磁盘文件、目录、管道、socket、字符设备、块设备甚至终端输入输出最终都抽象成文件描述符通过同一套open/read/write/close接口来操作。这意味着什么呢你学会了操作普通文件后面学socket编程、管道通信、设备驱动心智模型基本是平移的。比如网络socket有专门的send/recv接口但它在底层仍然依赖fd机制配合epoll、select监听时处理的照样是文件描述符命令管道pipe返回的两个fd本质也是文件描述符你往终端输出日志时用的fd就是系统默认分配好的标准输出。所以文件IO不是孤立知识点它是整个Linux系统编程的地基。很多人觉得网络编程难、高并发难追根溯源卡住的往往是“fd的状态转换”“缓冲区里到底有没有数据”“write没写完怎么处理”这类IO基本功。1.2 为什么先啃系统调用而不是直接用标准库日常写业务代码用fopen、fread、fwrite确实舒服C标准库帮你做了用户态缓冲接口更友好。但问题在于标准库把底层细节藏得太深一旦出问题你根本不知道它在背后做了什么。举个例子如果你混用read和fread操作同一个文件描述符大概率会读到奇怪的数据因为fread内部会把多余的数据吞进自己的缓冲区而read直接走内核两边数据不一致。再比如你想用O_DIRECT绕过页缓存做直IO标准库根本控制不了这个粒度处理非阻塞socket时EAGAIN这类errno是系统调用级别才存在的语义标准库接口包装之后很容易让你忽略真实错误码。我建议的学习路径是先用系统调用亲手搭一遍IO流程理解read/write的真实语义再去享受标准库的便利。面试也经常问“read的返回值有哪些含义”“为什么write要循环”这些问题不亲手写过真答不到点上。2. open与close文件描述符Linux世界里最值钱的整数2.1 open函数的两个签名以及flags和mode的细节open有两个常用签名#include sys/types.h #include sys/stat.h #include fcntl.h int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode);第二个签名多了一个mode参数只有在flags里带上O_CREAT时这个参数才会被用到。内核通过变长参数机制获取第三个参数如果没传就读取一个不确定的值所以该传的时候千万别漏否则创建出来的文件权限会很诡异。flags参数是这个函数的核心需要掌握的几类flags作用备注O_RDONLY只读打开值等于0O_WRONLY只写打开值等于1O_RDWR读写打开值等于2O_CREAT文件不存在则创建需要配合mode参数O_EXCL与O_CREAT连用文件已存在则失败防止覆盖的利器O_TRUNC打开同时把文件长度截断为0危险慎用O_APPEND每次写入追加到文件末尾对日志文件很关键mode是创建文件时的请求权限通常传0644或者0666。但它不是最终权限实际权限等于mode ~umask。比如系统umask是022你请求0666实际创建出来是0644因为组和其他用户的写权限被umask剥掉了。这个细节经常让新人困惑以为是open写错了。open失败时返回-1并设置errno。用perror或者strerror(errno)能直接看到原因比如ENOENT表示文件不存在EACCES表示权限不够EISDIR表示你试图用写方式打开一个目录。调试时养成先看errno的习惯比瞎猜快得多。2.2 返回值到底代表什么文件描述符的分配规则open成功返回一个非负整数这就是文件描述符。它本质上是进程文件描述符表的下标指向内核维护的打开文件描述。理解了这一点很多规则就顺理成章了。进程启动时0、1、2已经被占用分别对应标准输入、标准输出、标准错误。所以普通的open返回的第一个fd通常是3。内核分配fd的规则是从小到大找第一个空闲位置所以你连续open两个文件大概率得到3和4。如果先把fd 0关闭再open新的fd就可能是0shell的重定向机制利用的正是这个规则。文件描述符是一种进程级资源有数量上限。用ulimit -n可以查看传统默认是1024很多高并发服务会调大到65535甚至更高。如果一个进程只open不closefd数量越涨越高最终报Too many open files这就是典型的文件描述符泄漏。2.3 close和文件描述符泄漏一个常被忽略的资源管理问题close函数很简单作用就是把fd关掉让这个fd重新回到可分配状态。#include unistd.h int close(int fd);但简单归简单有几个习惯值得养成。第一打开文件后无论后续成功还是失败都要保证close被执行。我见过不少代码在错误分支里直接returnfd就这么泄漏了。第二不要重复close同一个fd。fd被关闭后可能被后续open复用你再close一次可能就把别人正在用的fd给关了这种bug极其隐蔽。第三close是“关闭fd”不保证数据立刻落到磁盘内核会按策略刷盘想强制落盘需要fsync。我把fd当成“借来的资源”——尽早打开用完马上还谁借谁还。尤其写长生命周期的服务时fd泄漏是慢刀割肉撑到某天突然全线报错排查起来非常痛苦。3. read与write别指望一次把文件读完3.1 read的返回值每次读到多少内核说了算read的原型长这样#include unistd.h ssize_t read(int fd, void *buf, size_t count);第一个参数是fd第二个参数是存放数据的缓冲区第三个是请求读取的最大字节数。返回值是重点返回值含义正数实际读到的字节数可能小于count0到达文件末尾EOF-1出错具体原因看errno新手最容易踩的误区是我请求读4096字节read就一定会返回4096。对于普通磁盘文件如果剩余数据足够通常确实会读满4096但如果文件只剩100字节read就只返回100面对管道、终端、socket这类特殊fd哪怕缓冲区还有大量数据内核也可能只给你一小部分具体返回多少由内核调度决定完全不可控。所以正确理解是这样的read的count是“最多读多少”不是“必须读多少”。想要安全地读完所有数据必须循环调用read直到返回0或者-1。这就是文件复制程序需要循环读的根本原因。3.2 write并不保证一次写完循环写入的必要性write的原型和read类似ssize_t write(int fd, const void *buf, size_t count);它返回实际写入的字节数。常规磁盘文件场景下write一般能一次写完count字节但这不是语言规范给你的保证。在socket或管道场景如果对端缓冲区不足write只会写入一部分甚至只写进去1个字节返回值就是那个部分字节数。一个严谨的写入逻辑必须这样处理记录已经写入的字节数如果write返回值小于剩余字节数就从buf的偏移位置继续写直到全部写完。这个“循环写”模式在网络编程里是保命代码很多初学者写的socket收发程序丢数据根因就是只调用了一次write没处理partial write。3.3 EINTR与EAGAIN信号和非阻塞带来的额外维度read和write返回-1时并不是所有错误都该直接退出。有两个errno需要特别认识。EINTR表示系统调用被信号打断。比如程序有一个定时器信号频繁触发read在等待数据时被打断内核就会返回-1并设置EINTR。这种错误不是致命的正确做法是重试这次调用。EAGAIN表示在非阻塞模式下当前没有数据可读或缓冲区已满不是错误而是“现在没条件你可以干别的事待会儿再试”。这在epoll模型里极其常见处理非阻塞socket时几乎天天见到。理解了这两个值你就能看懂很多生产级代码里为什么会有if (errno EINTR) continue;这种写法。4. 手写文件复制从需求到代码到跑通的完整过程4.1 需求拆解与设计决策缓冲区、打开方式和错误策略文件复制的需求很朴素给定源文件路径和目标文件路径把源文件内容逐个字节搬运到目标文件里。设计上有几个点要提前想清楚。一是缓冲区大小。这次取4096字节正好是一页大小也是实际项目里很常用的选择后面会专门分析性能和缓冲区的关系。二是打开方式。源文件用O_RDONLY只读打开目标文件用O_WRONLY | O_CREAT | O_TRUNC不存在就创建存在就截断重写。三是错误策略哪个环节失败都要有明确交代该关的fd必须关。顺便说一句复制过程不需要手动管理文件的进度内核为每个fd维护了独立的文件偏移量每read或write一次偏移量自动往后推这是系统给我们免费提供的便利。4.2 完整代码一个能跑且足够严谨的复制程序#include stdio.h #include stdlib.h #include unistd.h #include fcntl.h #include errno.h #define BUFFER_SIZE 4096 int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, Usage: %s source dest\n, argv[0]); exit(EXIT_FAILURE); } int src_fd open(argv[1], O_RDONLY); if (src_fd 0) { perror(open source); exit(EXIT_FAILURE); } int dst_fd open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0644); if (dst_fd 0) { perror(open dest); close(src_fd); exit(EXIT_FAILURE); } char buf[BUFFER_SIZE]; ssize_t nread; for (;;) { nread read(src_fd, buf, sizeof(buf)); if (nread 0) { if (errno EINTR) continue; perror(read); close(src_fd); close(dst_fd); return EXIT_FAILURE; } if (nread 0) break; /* EOF */ ssize_t written 0; while (written nread) { ssize_t nwrite write(dst_fd, buf written, nread - written); if (nwrite 0) { if (errno EINTR) continue; perror(write); close(src_fd); close(dst_fd); return EXIT_FAILURE; } written nwrite; } } close(src_fd); close(dst_fd); return 0; }外层的for循环解决“一次读不完”的问题一直读到返回0才认为到达文件末尾。内层while解决“一次写不完”的问题每次从buf的偏移位置继续写。遇到EINTR就continue重试遇到真正的错误就打印原因并回收fd。这段代码覆盖了前面讲的全部核心语义。提示代码里对read和write的EINTR都做了重试。对磁盘文件这种情况很少遇到但放到网络环境下就是必须的处理逻辑。保持这个习惯代码的健壮性会上一个台阶。4.3 编译、运行与验证用事实说话编译不需要链接额外库gcc -Wall -O2 filecopy.c -o filecopy准备一个测试文件运行echo hello file io test.txt ./filecopy test.txt copy.txt diff test.txt copy.txt echo OKdiff没有任何输出并打印OK说明两个文件内容一致。也可以顺便用md5sum校验md5sum test.txt copy.txt再试试异常场景。源文件不存在时程序会输出open source: No such file or directory。目标目录没有写权限时会输出open dest: Permission denied。目标文件原本有内容时由于O_TRUNC的存在它会被清空重写这一点在复制时要心里有数。注意想观察系统调用的真实过程可以跑一遍strace ./filecopy test.txt copy.txt你能亲眼看到open、read、write、close按顺序出现这比任何解释都直观。5. 复制性能实测与踩坑记录缓冲区大小、截断和偏移量的教训5.1 同样的代码为什么缓冲区大小不同性能差几倍每次read和write都是一次用户态到内核态的切换调用次数直接决定系统调用开销。假设文件大小是1GB用不同缓冲区大小系统调用次数差距非常直观缓冲区大小read调用次数write调用次数512字节约200万次约200万次4KB约25万次约25万次64KB约1.6万次约1.6万次1MB约1000次约1000次从512字节到64KB系统调用次数减少了128倍实测耗时会看到非常明显的变化尤其是在传统机械硬盘上。这也是为什么copy工具普遍默认使用较大缓冲区的原因。但缓冲区也不是越大越好单次请求过大时如果内核页缓存无法一次性满足反而可能在内核内部拆分处理用户态缓冲区太大会占用内存得不偿失。实践下来4KB起步64KB到1MB之间通常是比较理性的区间。给读者留个实验修改BUFFER_SIZE分别取512、4096、65536编译后用/usr/bin/time -v ./filecopy 大文件 目标文件对比输出你会对“系统调用是成本”这句话有切身体会。5.2 偏移量、截断与权限复制代码最容易翻车的三个隐蔽坑第一个坑是偏移量的误解。fd的偏移量在内核里是自动前进的这也是复制程序能正常跑完的原因。但有人会疑惑“为什么读完一遍之后再用同一个fd读不到任何数据”——不是文件被删了而是偏移量已经在文件末尾。想重新读就得close重新open或者用lseek把偏移量拨回去。第二个坑是O_TRUNC误用。现实中把源文件当成目标文件打开、顺手加O_TRUNC导致源文件被清空的事故并不少见。一旦open的fd指向源文件本身O_TRUNC会在你读取数据之前就把文件截成0字节复制出来的只能是一个空文件。如果目标是创建备份建议无论如何都先以只读方式验证源文件可打开再打开目标文件。第三个坑是权限和umask。前面说过open传0666实际权限可能变成0644。复制工具如果希望目标文件权限和源文件一致不能依赖mode参数需要在open之后再显式做权限调整。这些细节平时不会暴露但一旦需要精确控制文件权限就会被坑得很惨。5.3 从四个函数走向工程化标准库、零拷贝与更复杂的IO写业务代码追求效率时直接用标准库fopen/fread/fwrite是合理的它们内部封装的缓冲机制已经能处理大部分场景。但标准库解决不了的问题是零拷贝。sendfile系统调用允许内核直接把一个fd的数据拷贝到另一个fd完全不经用户态缓冲区复制大文件时的性能优势明显mmap加memcpy是另一条路适合需要随机访问文件的场景再往上的io_uring可以直接提交一批IO请求减少系统调用次数和上下文切换。但无论这些高级IO方案怎么变基本语义仍绕不开本文讲的东西fd代表什么read返回0是EOFwrite可能部分写入EINTR表示可以重试。遇到疑难问题时最终都要回到这四个函数建立的地基上思考问题。按我个人习惯复制小文件或写工具脚本直接cp或标准库就完事但排查性能问题、处理特殊设备、调试并发写入时我一定是回到open/read/write/close这套系统调用上想问题。建议你把这个复制程序改一改缓冲区大小跑一次time再盯着strace输出看几遍调用序列对Linux IO模型会有完全不一样的感觉。后面我还打算写一篇关于lseek偏移量、O_APPEND追加写和零拷贝进阶的内容到时候再聊。
