1.即使是空文件也要在磁盘中占用空间,因为文件=文件数据+文件属性,空文件没有文件数据但是仍然有文件属性。
2.因为文件=文件内容+文件属性,所以对文件的操作无非就是对内容/属性的操作。
3.在一个C程序中调用了文件操作函数,如果程序没有被执行这些文件操作函数也不会执行;只有这个程序被执行了这些文件操作函数才会被调用;因此文件操作的本质就是进程和被打开文件之间的关系
4.文件的唯一标识是“文件路径+文件名”,如果不指明路径默认是当前路径。
什么是当前路径?
当一个程序被执行时,其有关属性中有两个最显眼,一个是exe:表示当前执行的是哪个路径下的哪个程序;另一个是cwd:表示当前执行程序的工作目录
进程的工作目录就是这个进程的当前路径
Linux支持更改进程的当前路径,通过调用系统调用
chdir(要更改的路径名)
即可
fopen打开文件:
1.”w“以写方式打开,如果不存在就创建,默认是覆盖式写(清空文件原内容,写入新内容);
2.”r“以读方式打开,如果文件不存在就出错
3.”r+“读写方式打开,不存在出错
4.”w+“读写方式打开,不存在就创建
5.”a“追加打开,在文件原内容后面添加新内容
按照
%s%d
的格式将后面的参数写入到f所指向的文件中
只要改变打开方式即可
每种语言都有自己的文件操作函数,但是要想访问文件是无法绕过操作系统的,无论是文件的打开关闭还是读写都要经由操作系统之手,而我们要向操作系统发送请求就必须要调用系统调用。
也就是说无论何种语言的文件操作函数都是对文件方面的系统调用的再封装,但是它们各自的封装都是不同的。直接学习系统调用就能有效减少学习成本,因为上层语言是变化的,但是底层的系统调用不变,并且上层语言依赖于下层系统调用
标记位flags使用六个宏进行传参,他们分别是O_RDONLY(只读), O_WRONLY(只写),O_CREATE(创建), 和O_RDWR(读写),O_TRUNC(覆盖式写),O_APPEND(追加式写)
标记位利用了每个比特位只有01两种数字的特点,通过不同比特位中不同位置的1来表示不同的标记,所以对于flags中的五个宏的比特位序列一定是不同的
如果调用成功就返回打开文件的文件描述符,失败就返回-1
与open对应的系统调用接口是close,在打开文件以后最好手动调用close关闭文件
在我们使用C语言的文件操作函数时,以写方式打开文件如果文件不存在就会自动创建;但是系统调用这里即使是写方式打开不存在的文件也会出错,因为C语言的文件操作函数在调用系统调用是flags传的参数是O_WRONLY|O_CREATE
文件在创建时默认权限是666,目录是777,但是还要受到系统umask码值的影响,最终的权限是:默认权限&~umsak
当我们开始使用系统调用时发现相比语言来说操作并不是那么简单随意,因为此时语言所做的事就由我们自己来做了(我们长大了哦)
C语言创建文件默认的权限是正确的是因为它在使用open
函数时还使用了第三个参数:
如果文件已经存在就没必要在打开文件时还传入第三个权限参数
如果不想受系统umask的影响,可以使用系统调用
umask
来更改
这个输出结果好像不太对劲,虽然将wb和cnt正确输出了,但是为什么最后还有一个wbm1呢?
write是覆盖式写,并不会自动将文件清空,除非在open的时候加入
O_TRUNC
如果不想直接覆盖式写,可以将O_TRUNC
改成O_APPEND
将fd代表的文件中的数据读取到buf所代表的缓冲区中
一个系统中一定存在着大量的被打开的文件,这些文件要被管理起来,因此操作系统对文件先描述后组织形成了struct file{}结构体,这个结构体包含了文件的大部分属性。
不但文件要被管理起来,每个文件的内核数据结构(struct file)也要被管理起来,所有就有了文件描述表(struct file_struct)。此时至少有一个这样的认识:
一个进程可能打开不止一个文件,同时内存中又存在大量被打开的文件,那么进程如何知道哪些文件是属于自己的呢?答案是通过文件描述符表,文件描述符表是一个数组指针,它的每一个元素都是一个指针,指向一个文件的内核数据结构,每个进程的PCB中都有一个指针指向文件描述符表。
现在将结构补全:
每个进程的PCB中都存放了一个文件描述符表指针,通过这个指针就可以找到文件描述符表,该进程文件描述符表中元素所指向的文件都是该进程的文件
通过上面的结构我们就很清楚的知道为什么当我打开一个文件时这个返回值是3,这个返回值其实是文件描述符的下标;
系统会默认打开标准输入流,标准输出流和标准错误,它们分别占了文件描述符的0,1,2下标,所以新打开的文件只能占用3下标了。
想要访问文件绕不开操作系统,想让操作系统帮你找到某一个文件,你必须要有这个文件的文件描述符。因此,FILE这个结构体中必定要有文件描述符fd。
系统调用close
是用来关闭文件的,那么我可以关闭默认打开的三个标准文件吗?
0下标的文件被关闭以后,新打开的文件下标就是0。这是因为文件描述符的分配规则是自上到下扫描找到最小且没有被占用的下标分配给新打开的文件
当我将1关闭以后,再执行myfile,并没有输出任何东西,这点足以证明即使是三个默认被打开的文件也是可以通过
close
关闭的。当我把1关闭以后,我新打开的文件就变成了那下标为1的文件,也就是说标准输出从显示器变成了我刚打开的文件,内容应该是输入到文件中了,我们打开文件看看:
为什么什么也没有?
因为这里还涉及到一个缓冲区的问题,向显示器中刷新数据和文件中刷新的策略是不一样的
我将本来应该打印到显示器上的内容打印到了文件中,这正好输出重定向
将本该打印到显示器的内容打印到某个指定的文件中就是输出重定向,所以说重定向的本质就是上层用的fd不变,在内核中更改fd对应struct file*的指向。
改变标准输入/输出的本质是改变文件描述符表中0,1下标的内容
在文件描述符分配规则中先关闭标准输入/输出,在打开一个新文件,此时这个新文件就会占用刚刚关闭的标准输入/输出流的位置,这是一种改变方法,但这样写有些太挫。
操作系统提供了dup2
的系统调用,用于改变标准输入/输出:
dup2就是将oldfd中的内容,拷贝到newfd中
通过dup2系统调用就能很轻松的实现重定向的功能。
因此之间的输出重定向可以写成这样:
结果变成了3,这是因为dup2是一种拷贝,最后newfd和oldfd都变成了oldfd的内容,也就是说新打开的文件仍然是被文件描述符表中的3下标中的指针指向,但是代表标准输出的0下标中的struct file*也指向了新打开的文件。
追加重定向也是输出重定向的一种,原本追加的内容是直接打印到显示器上,现在也放到了文件中
所谓输入重定向就是将文件中的内容读取出来并打印到显示器上
子进程的重定向不会影响父进程,子进程在创建时是以父进程为模型的,它会拷贝父进程的部分内核数据结构其中就包括了文件描述符表,子进程中文件描述符表的struct file*的指向变了,关我父进程什么事。
进程具有独立性,所有它们的文件描述符表也是各自持有一份。
一切皆文件的难点在于如何将硬件也作为文件来看待:
操作系统对每一个文件先描述后组织形成了struct file内核数据结构,在这个内核数据结构中存放了文件的大部分属性,其中还包含着一大批函数指针,这些函数指针指向的是某个文件的具体读写方法。
虽然每个文件都是不一样的,但是文件的属性有很大的相似性,为了方便管理可以将文件抽象成文件属性,对文件的描述就是对文件的属性描述,因为管理的本质是对数据进行管理。
将硬件用同样的方式来管理,将硬件的读写方法抽象成函数指针,各种属性抽象到struct file内核数据结构中。
当我站在struct file之上来看,所有的东西包括硬件都是统一由struct file来管理的,所以对我来说硬件也就和文件一样了。因此就造成了一种一切皆文件的现象。