今日头条/西瓜视频/抖音短视频 同名：正点原子原子哥
感谢各位的关注和支持，你们的支持是原子哥无限前进的动力。
第三章 深入探究文件I/O
由于本章内容较多，所以第三章 深入探究文件I/O将会分为几个部分进行内容的发布，更多精彩原创文章请持续关注正点原子原子哥官方账号。
一.1 空洞文件
一.1.1 概念
什么是空洞文件（hole file）？在上一章内容中，笔者给大家介绍了lseek()系统调用，使用lseek可以修改文件的当前读写位置偏移量，此函数不但可以改变位置偏移量，并且还允许文件偏移量超出文件长度，这是什么意思呢？譬如有一个test_file，该文件的大小是4K（也就是4096个字节），如果通过lseek系统调用将该文件的读写偏移量移动到偏移文件头部6000个字节处，大家想一想会怎样？如果笔者没有提前告诉大家，大家觉得不能这样操作，但事实上lseek函数确实可以这样操作。
接下来使用write()函数对文件进行写入操作，也就是说此时将是从偏移文件头部6000个字节处开始写入数据，也就意味着4096~6000字节之间出现了一个空洞，因为这部分空间并没有写入任何数据，所以形成了空洞，这部分区域就被称为文件空洞，那么相应的该文件也被称为空洞文件。
文件空洞部分实际上并不会占用任何物理空间，直到在某个时刻对空洞部分进行写入数据时才会为它分配对应的空间，但是空洞文件形成时，逻辑上该文件的大小是包含了空洞部分的大小的，这点需要注意。
那说了这么多，空洞文件有什么用呢？空洞文件对多线程共同操作文件是及其有用的，有时候我们创建一个很大的文件，如果单个线程从头开始依次构建该文件需要很长的时间，有一种思路就是将文件分为多段，然后使用多线程来操作，每个线程负责其中一段数据的写入；这个有点像我们现实生活当中施工队修路的感觉，比如说修建一条高速公路，单个施工队修筑会很慢，这个时候可以安排多个施工队，每一个施工队负责修建其中一段，最后将他们连接起来。
来看一下实际中空洞文件的两个应用场景：
l 在使用迅雷下载文件时，还未下载完成，就发现该文件已经占据了全部文件大小的空间，这也是空洞文件；下载时如果没有空洞文件，多线程下载时文件就只能从一个地方写入，这就不能发挥多线程的作用了；如果有了空洞文件，可以从不同的地址同时写入，就达到了多线程的优势；
l 在创建虚拟机时，你给虚拟机分配了100G的磁盘空间，但其实系统安装完成之后，开始也不过只用了3、4G的磁盘空间，如果一开始就把100G分配出去，资源是很大的浪费。
关于空洞文件，这里就介绍这么多，上述描述当中多次提到了线程这个概念，关于线程这是后面的内容，这里先不给大家讲。
一.1.2 实验测试
这里我们进行相关的测试，新建一个文件把它做成空洞文件，示例代码如下所示：
示例代码 3.4.1 空洞文件测试代码
#include <sy;
#include <sy;
#include <;
#include <uni;
#include <;
#include <;
#include <;
int main(void)
{
int fd;
int ret;
char buffer[1024];
int i;
/* 打开文件 */
fd = open("./hole_file", O_WRONLY | O_CREAT | O_EXCL,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
if (-1 == fd) {
perror("open error");
exit(-1);
}
/* 将文件读写位置移动到偏移文件头4096个字节(4K)处 */
ret = lseek(fd, 4096, SEEK_SET);
if (-1 == ret) {
perror("lseek error");
goto err;
}
/* 初始化buffer为0xFF */
memset(buffer, 0xFF, sizeof(buffer));
/* 循环写入4次，每次写入1K */
for (i = 0; i < 4; i++) {
ret = write(fd, buffer, sizeof(buffer));
if (-1 == ret) {
perror("write error");
goto err;
}
}
ret = 0;
err:
/* 关闭文件 */
close(fd);
exit(ret);
}示例代码中，我们使用open函数新建了一个文件hole_file，在Linux系统中，新建文件大小是0，也就是没有任何数据写入，此时使用lseek函数将读写偏移量移动到4K字节处，再使用write函数写入数据0xFF，每次写入1K，一共写入4次，也就是写入了4K数据，也就意味着该文件前4K是文件空洞部分，而后4K数据才是真正写入的数据。
接下来进行编译测试，首先确保当前文件目录下不存在hole_file文件，测试结果如下：
示例代码 3.4.2 空洞文件测试结果
使用ls命令查看到空洞文件的大小是8K，使用ls命令查看到的大小是文件的逻辑大小，自然是包括了空洞部分大小和真实数据部分大小；当使用du命令查看空洞文件时，其大小显示为4K，du命令查看到的大小是文件实际占用存储块的大小。
本小节内容就讲解完了，最后再向各位抛出一个问题：若使用read函数读取文件空洞部分，读取出来的将会是什么？关于这个问题大家可以先思考下，至于结果是什么，笔者这里便不给出答案了，大家可以自己动手编写代码进行测试以得出结论。
一.2 O_APPEND和O_TRUNC标志
在上一章给大家讲解open函数的时候介绍了一些open函数的flags标志，譬如O_RDONLY、O_WRONLY、O_CREAT、O_EXCL等，本小节再给大家介绍两个标志，分别是O_APPEND和O_TRUNC，接下来对这两个标志分别进行介绍。
一.2.1 O_TRUNC标志
O_TRUNC这个标志的作用非常简单，如果使用了这个标志，调用open函数打开文件的时候会将文件原本的内容全部丢弃，文件大小变为0；这里我们直接测试即可！测试代码如下所示：
示例代码 3.5.1 O_TRUNC标志测试
#include <sy;
#include <sy;
#include <;
#include <uni;
#include <;
#include <;
int main(void)
{
int fd;
/* 打开文件 */
fd = open("./test_file", O_WRONLY | O_TRUNC);
if (-1 == fd) {
perror("open error");
exit(-1);
}
/* 关闭文件 */
close(fd);
exit(0);
}在当前目录下有一个文件test_file，测试代码中使用了O_TRUNC标志打开该文件，代码中仅仅只是打开该文件，之后调用close关闭了文件，并没有对其进行读写操作，接下来编译运行来看看测试结果：
图 3.5.1 O_TRUNC测试结果
在测试之前test_file文件中是有数据的，文件大小为8760个字节，执行完测试程序后，再使用ls命令查看文件大小时发现test_file大小已经变成了0，也就是说明文件之前的内容已经全部被丢弃了。这就是O_TRUNC标志的作用了，大家可以自己动手试试。
一.2.2 O_APPEND标志
接下里聊一聊O_APPEND标志，如果open函数携带了O_APPEND标志，调用open函数打开文件，当每次使用write()函数对文件进行写操作时，都会自动把文件当前位置偏移量移动到文件末尾，从文件末尾开始写入数据，也就是意味着每次写入数据都是从文件末尾开始。这里我们直接进行测试，测试代码如下所示：
示例代码 3.5.2 O_APPEND标志测试
#include <sy;
#include <sy;
#include <;
#include <uni;
#include <;
#include <;
#include <;
int main(void)
{
char buffer[16];
int fd;
int ret;
/* 打开文件 */
fd = open("./test_file", O_RDWR | O_APPEND);
if (-1 == fd) {
perror("open error");
exit(-1);
}
/* 初始化buffer中的数据 */
memset(buffer, 0x55, sizeof(buffer));
/* 写入数据: 写入4个字节数据 */
ret = write(fd, buffer, 4);
if (-1 == ret) {
perror("write error");
goto err;
}
/* 将buffer缓冲区中的数据全部清0 */
memset(buffer, 0x00, sizeof(buffer));
/* 将位置偏移量移动到距离文件末尾4个字节处 */
ret = lseek(fd, -4, SEEK_END);
if (-1 == ret) {
perror("lseek error");
goto err;
}
/* 读取数据 */
ret = read(fd, buffer, 4);
if (-1 == ret) {
perror("read error");
goto err;
}
printf("0x%x 0x%x 0x%x 0x%x\n", buffer[0], buffer[1],
buffer[2], buffer[3]);
ret = 0;
err:
/* 关闭文件 */
close(fd);
exit(ret);
}测试代码中会去打开当前目录下的test_file文件，使用可读可写方式，并且使用了O_APPEND标志，前面笔者给大家提到过，open打开一个文件，默认的读写位置偏移量会处于文件头，但测试代码中使用了O_APPEND标志，如果O_APPEND确实能生效的话，也就意味着调用write函数会从文件末尾开始写；代码中写入了4个字节数据，都是0x55，之后,使用lseek函数将位置偏移量移动到距离文件末尾4个字节处，读取4个字节（也就是读取文件最后4个字节数据），之后将其打印出来，如果上面笔者的描述正确的话，打印出来的数据就是我们写入的数据，如果O_APPEND不能生效，则打印出来数据就不会是0x55，接下来编译测试：
图 3.5.2 O_APPEND标志测试结果
从上面打印信息可知，读取出来的数据确实等于0x55，说明O_APPEND标志确实有作用，当调用write()函数写文件时，会自动把文件当前位置偏移量移动到文件末尾。
当然，本小节内容还并没有结束，这其中还涉及到一些细节问题需要大家注意，首先第一点，O_APPEND标志并不会影响读文件，当读取文件时，O_APPEND标志并不会影响读位置偏移量，即使使用了O_APPEND标志，读文件位置偏移量默认情况下依然是文件头，关于这个问题大家可以自己进行测试，编程是一个实践性很强的工作，有什么不能理解的问题，可以自己编写程序进行测试。
大家可能会想到使用lseek函数来改变write()时的写位置偏移量，其实这种做法并不会成功，这就是笔者给大家提的第二个细节，使用了O_APPEND标志，即使是通过lseek函数也是无法修改写文件时对应的位置偏移量（注意笔者这里说的是写文件，并不包括读），写入数据依然是从文件末尾开始，lseek并不会该变写位置偏移量，这个问题测试方法很简单，也就是在write之前使用lseek修改位置偏移量，这里笔者就不再给大家测试了，我还是那句话，编程是一个实践性很强的工作，大家只需要把示例代码 3.5.2进行简单地修改即可！
其实关于第二点细节原因很简单，当执行write()函数时，检测到open函数携带了O_APPEND标志，所以在write函数内部会自动将写位置偏移量移动到文件末尾，当然这里也只是笔者的一个简单地猜测，至于是不是这样，笔者也无从考证。
到这里本小节的内容就暂时介绍完了，为什么说是“暂时”？因为后面的内容中还会聊到O_APPEND标志，最后笔者再给大家出一个小问题，大家可以自己动手测试。
u 当open函数同时携带了O_APPEND和O_TRUNC两个标志时会有什么作用？
一.3 多次打开同一个文件
大家看到这个小节标题可能会有疑问，同一个文件还能被多次打开？事实确实如此，同一个文件可以被多次打开，譬如在一个进程中多次打开同一个文件、在多个不同的进程中打开同一个文件，那么这些操作都是被允许的。本小节就来探讨下多次打开同一个文件会有一些什么现象以及相应的细节问题？
一.3.1 验证一些现象
l 一个进程内多次open打开同一个文件，那么会得到多个不同的文件描述符fd，同理在关闭文件的时候也需要调用close依次关闭各个文件描述符。
针对这个问题，我们编写测试代码进行测试，如下所示：
示例代码 3.6.1 多次打开同一个文件测试代码1
#include <sy;
#include <sy;
#include <;
#include <uni;
#include <;
#include <;
int main(void)
{
int fd1, fd2, fd3;
int ret;
/* 第一次打开文件 */
fd1 = open("./test_file", O_RDWR);
if (-1 == fd1) {
perror("open error");
exit(-1);
}
/* 第二次打开文件 */
fd2 = open("./test_file", O_RDWR);
if (-1 == fd2) {
perror("open error");
ret = -1;
goto err1;
}
/* 第三次打开文件 */
fd3 = open("./test_file", O_RDWR);
if (-1 == fd3) {
perror("open error");
ret = -1;
goto err2;
}
/* 打印出3个文件描述符 */
printf("%d %d %d\n", fd1, fd2, fd3);
close(fd3);
ret = 0;
err2:
close(fd2);
err1:
/* 关闭文件 */
close(fd1);
exit(ret);
}上述示例代码中，通过3次调用open函数对test_file文件打开了3次，每一个调用传参一样，最后将3次得到的文件描述符打印出来，在当前目录下存在test_file文件，接下来编译测试，看看结果如何：
图 3.6.1 打印文件描述符
从打印结果可知，三次调用open函数得到的文件描述符分别为6、7、8，通过任何一个文件描述符对文件进行IO操作都是可以的，但是需要注意是，调用open函数打开文件使用的是什么权限，则返回的文件描述符就拥有什么权限，文件IO操作完成之后，在结束进程之前需要使用close关闭各个文件描述符。
在图 3.6.1中，细心的读者可能会发现，调用open函数得到的最小文件描述符是6，在上一章节内容中给大家提到过，程序中分配得到的最小文件描述符一般是3，但这里竟然是6！这是为何？其实这个问题跟vscode有关，说明3、4、5这3个文件描述符已经被vscode软件对应的进程所占用了，而当前这里执行testApp文件是在vscode软件提供的终端下进行的，所以vscode可以认为是testApp进程的父进程，相反，testApp进程便是vscode进程的子进程，子进程会继承父进程的文件描述符。关于子进程和父进程这些都是后面的内容，这里暂时不给大家进行介绍，这是只是给大家简单地解释一下，免得大家误会！
其实可以直接在Ubuntu系统的Terminal终端执行testApp，这时你会发现打印出来的文件描述符分别是3、4、5，这里就不给大家演示了。
l 一个进程内多次open打开同一个文件，在内存中并不会存在多份动态文件。
当调用open函数的时候，会将文件数据（文件内容）从磁盘等块设备读取到内存中，将文件数据在内存中进行维护，内存中的这份文件数据我们就把它称为动态文件！这是前面给大家介绍的内容，这里再简单地提一下。这里出现了一个问题：如果同一个文件被多次打开，那么该文件所对应的动态文件是否在内存中也存在多份？也就是说，多次打开同一个文件是否会将其文件数据多次拷贝到内存中进行维护？
关于这个问题，各位读者可以简单地思考一下，这里我们直接编写代码进行测试，测试代码如下所示：
示例代码 3.6.2 多次打开同一个文件测试代码2
#include <sy;
#include <sy;
#include <;
#include <uni;
#include <;
#include <;
#include <;
int main(void)
{
char buffer[4];
int fd1, fd2;
int ret;
/* 创建新文件test_file并打开 */
fd1 = open("./test_file", O_RDWR | O_CREAT | O_EXCL,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
if (-1 == fd1) {
perror("open error");
exit(-1);
}
/* 再次打开test_file文件 */
fd2 = open("./test_file", O_RDWR);
if (-1 == fd2) {
perror("open error");
ret = -1;
goto err1;
}
/* 通过fd1文件描述符写入4个字节数据 */
buffer[0] = 0x11;
buffer[1] = 0x22;
buffer[2] = 0x33;
buffer[3] = 0x44;
ret = write(fd1, buffer, 4);
if (-1 == ret) {
perror("write error");
goto err2;
}
/* 将读写位置偏移量移动到文件头 */
ret = lseek(fd2, 0, SEEK_SET);
if (-1 == ret) {
perror("lseek error");
goto err2;
}
/* 读取数据 */
memset(buffer, 0x00, sizeof(buffer));
ret = read(fd2, buffer, 4);
if (-1 == ret) {
perror("read error");
goto err2;
}
printf("0x%x 0x%x 0x%x 0x%x\n", buffer[0], buffer[1],
buffer[2], buffer[3]);
ret = 0;
err2:
close(fd2);
err1:
/* 关闭文件 */
close(fd1);
exit(ret);
}当前目录下不存在test_file文件，上述代码中，第一次调用open函数新建并打开test_file文件，第二次调用open函数再次打开它，新建文件时，文件大小为0；首先通过文件描述符fd1写入4个字节数据（0x11/0x22/0x33/0x44），从文件头开始写；然后再通过文件描述符fd2读取4个字节数据，也是从文件头开始读取。假如，内存中只有一份动态文件，那么读取得到的数据应该就是0x11、0x22、0x33、0x44，如果存在多份动态文件，那么通过fd2读取的是与它对应的动态文件中的数据，那就不是0x11、0x22、0x33、0x44，而是读取出0个字节数据，因为它的文件大小是0。
接下来进行编译测试：
图 3.6.2 测试结果2
上图中打印显示读取出来的数据是0x11/0x22/0x33/0x44，所以由此可知，即使多次打开同一个文件，内存中也只有一份动态文件。
l 一个进程内多次open打开同一个文件，不同文件描述符所对应的读写位置偏移量是相互独立的。
同一个文件被多次打开，会得到多个不同的文件描述符，也就意味着会有多个不同的文件表，而文件读写偏移量信息就记录在文件表数据结构中，所以从这里可以推测不同的文件描述符所对应的读写偏移量是相互独立的，并没有关联在一起，并且文件表中i-node指针指向的都是同一个inode，如下图所示：
图 3.6.3 多次打开同一个文件--文件描述符表、文件表以及inode之间的关系
测试的方法很简单，只需在示例代码 3.6.2中简单地修改即可，将lseek函数调用去掉，然后在编译测试，如果读出的数据依然是0x11/0x22/0x33/0x44，则表示第三点结论成立，这里不再给大家演示。
Tips：多个不同的进程中调用open()打开磁盘中的同一个文件，同样在内存中也只是维护了一份动态文件，多个进程间共享，它们有各自独立的文件读写位置偏移量。
动态文件何时被关闭呢？当文件的引用计数为0时，系统会自动将其关闭，同一个文件被打开多次，文件表中会记录该文件的引用计数，如图 3.1.5所示，引用计数记录了当前文件被多少个文件描述符fd关联。
