write

向一个fd里写特定的buf，字符个数为conut

修改一下再写入

我们发现是从头部开始写入，而不是删除后再写

这是因为我们加的指令不够

追加O_APPEND

read

从特定文件描述符，读取数据到buf中，读count个

read返回值是实际读到的字节数

文件描述符

我们发现上面打开文件后，描述符都是3

文件描述符没有0，1，2

这是因为：0，1，2，分别对应stdin,stdout,stderr

证明：

我们发现往标准输出和往1里面写，照样可以打印在显示器上

我们输入123456，仍然可以打印出来

此时仍然可以读取

int类型 0 1 2 和FILE*类型 stdin stdout stderr都可以读取

FILE*的FILE是一个struct结构体，是C标准库提供的，内部有多种成员

C文件库函数内部一定要调用系统调用，在系统角度，系统认的是fd而不是FILE

FILE结构体里面必定封装了fd

stdin/out/err内部绝对有fd

fd的理解

进程要访问文件，必须先打开文件，一个进程可以打开多个文件，一般而言 进程：打开的文件=1：N，文件要被访问，前提是加载到内存当中

如果多个进程都要打开自己的文件，系统中会存在大量被打开的文件，所以,OS需要把如此多的文件管理起来，管理方式：先描述，再组织

在内核中，OS内部要为管理每一个被打开的文件，构建struct file结构体，打开一个文件就创建struct file的对象或变量，用来充当一个被打开的文件，结构体里面包含了一个被打开的文件的几乎所有的内容（不仅仅包含属性）

如果有很多创建的struct file，会用双链表组织起来

进程和文件的对应关系，用一个数组维护类型是struct file*

fd在内核中，本质是一个数组下标，系统通过数组下标，在数组中做哈希索引，就可以找到对应的打开的文件对象

结论：

当我们使用open打开文件的时候，内核中会创建一个文件对象，然后在数组里找一个没有被使用的格子，把这个格子的地址填到右侧创建的文件对象中，然后把对应的数组下标返回给用户。用户用数组下标就能调用接口，直接根据当前进程的PCB找到数组，然后根据数组索引到文件对象，文件对象中包含了文件的所有内容，找到文件之后，就可以进行操作