1、回顾C语言中的文件接口

事实上，我们在C语言的学习中了解的文件并不是真正的文件。从语言角度来说，我们没有真正的理解文件的含义 。又由于所有的语言几乎都能够对文件就行操作，但是每一个语言都不相同，谁给的勇气让他这么做呢？那一定是操作系统啊，在操作系统方面上的相同，让文件操作有着多种的可能，所以我们想要真正的理解文件，我们就得从操作系统上来理解。 但是我们还是，首先回顾先回顾一下代码的层次。

对于“W”来说，表示的含义是如果不存在，就在当前目录下，新建指定的文件。默认打开文件的话，会先默认清空文件中的内容。
但是，这个写完的程序在进行的时候，程序怎么知道，在哪里找文件，程序怎么知道没有文件之后，直接就在所谓的当前目录下就直接创建的呢？
问题就是可执行程序是如何知道在当前目录之下？ 答案是打开文件是在进程的基础下打开的，进程在启动的时候，就会有当前进程的运行的工作路径。所以打开文件，创建文件都在这个路径下创建的。
我们进行文件操作，前提是我们的程序跑起来了，文件打开和关闭，都是CPU在执行我们的代码。
除此之外，还有“a”操作，他的含义就是追加，不会清空文件

2、对文件的理解(阶段一)

所以，对文件的打开其实就是进程打开文件。
文件没有被打开的时候，会存在于磁盘上。
一个进程也能打开很多文件。 一个系统中又能够存在多个进程，所以很多时候，OS系统内部，一定存在大量的被打开的文件，所以大量的打开的文件，OS必须要对这些文件进行合理的管理。怎么管理呢？先描述，再组织。所以可以大胆的猜一猜，对于每一个被打开的文件。在OS内部，一定存在这对应的描述文件属性的结构体，类似PCB。
所以最后在内核进程的结构体中，我们应该能够看到PCB的结构体内部，有指向一个对文件属性控制的结构体指针。
不止是这些的C语言中的对于代码的修改，在Linux操作系统上的echo进行重定向，也能够对文件内容进行修改，所以输出重定向一定是文件操作，并且每次重定向写入的方式是先清空，再写入，其实根本上，这个输出重定向也就是按照w的方式进行打开的。
所以既然知道了 > 的含义就是w的方式打开文件，那我们也能够这样直接创建文件。也能够直接 > 的方式重新刷新文件内容。

当然，> 表示的是w，那么其中也有表示a的含义的命令行，那就是>> ,表示的就是按照a方式打开。

3、文件操作

3、1、C++的文件操作接口

1、操作文件，本质上就是进程在操作文件，进程和文件之间的关系。
2、文件->磁盘->外设->硬件(所以向文件中写入，本质就是向硬件中写入)->但是用户没有权利直接向硬件写入->OS是硬件的管理者->所以要通过OS来写入->OS必须给我们提供系统调用(OS不相信任何人)->但是我们能够通过这些的函数fopen/fclose/fwrite/fread/fprintf/scanf/printf/cin/cout对硬件进行操作 ->所以我们使用的C/C++/…都是对系统调用接口的封装。
上面介绍了C语言的对于文件的操作，下面简单看一下C++对于文件的操作。


所以能看的出来，各种语言进行访问文件都有些不一样，难道每次都要记住不同语言的对于文件操作的函数吗？

3、2、认识系统调用接口

其中的pathname可以带路径，也可以带文件名。如果只是文件名的话，就在当前的路径下创建文件。
其中flag是一个整数，代表的是，我们想怎么样的操作文件。
open函数的第一种方式代表的通常都是操作一些已经存在的文件，因为如果直接创建的话，在Linux操作系统中，我们不知道，我们创建的文件的权限是什么，所以说有的时候还会让我们创建的文件的权限出现乱码的情况。

出现了我们不知道的权限T。
当然即使是使用第二种的open直接设置我们文件的权限的值了，最后看我们创建的文件的属性也还是不对。 那是因为还有umask的存在，会让我们的文件最后的权限有点区别。之前文章中介绍过，如果忘记了，可以回去看看，这里介绍了掩码的概念。
所以那我们能不能在程序中动态的规划掩码的值呢？
可以！我们能够通过系统调用来实现。



此时一个简单的系统调用实现的文件操作就完成了。但是应该还有疑问，困惑为什么open传参的是整数，却传了O_WRONLY | O_CREAT呢?还有这两个是什么东西呢？
那是因为，在这地方的文件的操作方法有很多的组合方式，我们不确定每一使用的是什么，那么难道说，就要每一种方法都写出来一种函数吗？不能！所以根据操作方式最多也就传一传0，1，2…等等之类的，也不对太多，所以说一个整数的32位置，也就能够配合的很好的来解释操作方法。我们能够通过 | 操作，将32位的每一位都能够代表一种操作方式，这样能够节省大量的代码冗余问题。 类似于位图的使用？—OS设计中很多系统调用接口的常见方法(很重要，会实现，并加深理解)。并且其中的两个在这里的大写的英文字母表示的是宏。所以为了更方便的理解设计可以直接稍微手撕一个传递位图标记位的函数来方便我们的理解。


这样我们在传参的时候，就不需要多个的int来写，直接这样就能多个数传参。
如果只是想上面代码中利用open的参数的话，此时在文件中写东西的时候不会每次重写都要刷新文件，只会继续在前面追加后来写的内容。如果想要每次写的时候都全部刷新一遍的话，就需要再加上一个操作。

这样就完成了，写方式打开，不存在就创建，存在就在写之前都要先清—相当于是C语言中的fopen的“w”操作。
当然了，这么多的操作的方法，其中肯定也有类似于像是“r”的操作，就比如说是O_APPEDND。

只需要改变这一行中的一点，就能够实现在文件末尾直接添加。

3、2、强化对fd文件描述符及周边知识的理解

上面已经有了两个问题了，分别是对文件的写和追加问题，系统与语言层面的关系到底是什么。
现在还有一个问题就是open的返回值问题
我们可以通过程序来帮助我们来判断返回值是什么。


可是我们函数的返回值为什么是从3开始的呢？
那是因为文件操作的前面的0，1，2，已经有了它们的含义。

0：代表的是标准输入 键盘
1：代表的是标准输出 显示器
2：代表的是标准错误 显示器
这三个是默认打开的并且我们看到这三个都还和文件指针是一个样子的。
所以系统调用的open返回值和语言层面的stdin，stdout，stderr之间是不是也存在着关系？
这个问题的突破口就是，当我们打印open的返回值的时候，第一个就是3，此时，并不是代表前面的没有反而是一直存在的，那么我们write的函数不也能直接向2里面打印，看看是不是显示在显示器上，不就能够证明之间确实存在关系。


所以之前的0，1，2，不仅仅是表示的数字，也表示的标准输入/输出/错误。
虽然他不仅仅表示数字，但是我们怎么样做到，能够向数字来作为根据，打开一个文件，然后对文件开始操作呢？
所以问题就是文件描述符号fd，fd的本质是什么？

其中文件内核级别的缓存存储的是文件的数据，结构体struct file存储的是文件的属性。
本质表示的是内核进程中的文件映射关系的数组的下标。
无论读写文件，都需要再合适的时候让OS把文件的内容加载到文件缓冲区中。
open是在做什么？
1、创建file 2、开辟文件缓冲区的空间，加载文件数据 3、查进程的文件描述表 4、file地址填入对应的表小表中 5、返回下标
话又说回来，其实read和write函数本质上也就是拷贝函数。
由于Linux操作系统一切皆文件，所以其中显示器，键盘的外设，也能够存在于sturct file链表中，所以就有了之前的0，1，2。
对于硬件来说的一切皆文件示意图。

这样的话，我们在OS层面再向上看的时候，就不再需要关注每一个硬件之间的差异了。所以一切皆文件了。所以我们刚刚的struct files_struct列表中才会有0，1，2的属于硬件的位置。
其中的struct file不管是对于文件也好，硬件也罢，这也相当于是在C++中的多态。