3.1.5.open函数的flag详解2

3.1.5.1、打开不存在的文件时：O_CREAT、O_EXCL

(1)思考：当我们去打开一个并不存在的文件时会怎样？当我们open打开一个文件时如果这个文件名不存在则会打开文件错误。 (2)vi或者windows下的notepad++，都可以直接打开一个尚未存在的文件。 (3)open的flag O_CREAT就是为了应对这种打开一个并不存在的文件的。O_CREAT就表示我们当前打开的文件并不存在，我们是要去创建并且打开它。 (4)思考：当我们open使用了O_CREAT，但是文件已经存在的情况下会怎样？经过实验验证发现结果是报错。 (5)结论：open中加入O_CREAT后，不管原来这个文件存在与否都能打开成功，如果原来这个文件不存在则创建一个空的新文件，如果原来这个文件存在则会重新创建这个文件，原来的内容会被消除掉（有点类似于先删除原来的文件再创建一个新的） (6)这样可能带来一个问题？我们本来是想去创建一个新文件的，但是把文件名搞错了弄成了一个老文件名，结果老文件就被意外修改了。我们希望的效果是：如果我CREAT要创建的是一个已经存在的名字的文件，则给我报错，不要去创建。 (7)这个效果就要靠O_EXCL标志和O_CREAT标志来结合使用。当这连个标志一起的时候，则没有文件时创建文件，有这个文件时会报错提醒我们。 (8)open函数在使用O_CREAT标志去创建文件时，可以使用第三个参数mode来指定要创建的文件的权限。mode使用4个数字来指定权限的，其中后面三个很重要，对应我们要创建的这个文件的权限标志。譬如一般创建一个可读可写不可执行的文件就用0666

3.1.5.2、O_NONBLOCK

(1)阻塞与非阻塞。如果一个函数是阻塞式的，则我们调用这个函数时当前进程有可能被卡住（阻塞住，实质是这个函数内部要完成的事情条件不具备，当前没法做，要等待条件成熟），函数被阻塞住了就不能立刻返回；如果一个函数是非阻塞式的那么我们调用这个函数后一定会立即返回，但是函数有没有完成任务不一定。 (2)阻塞和非阻塞是两种不同的设计思路，并没有好坏。总的来说，阻塞式的结果有保障但是时间没保障；非阻塞式的时间有保障但是结果没保障。 (3)操作系统提供的API和由API封装而成的库函数，有很多本身就是被设计为阻塞式或者非阻塞式的，所以我们应用程度调用这些函数的时候心里得非常清楚。 (4)我们打开一个文件默认就是阻塞式的，如果你希望以非阻塞的方式打开文件，则flag中要加O_NONBLOCK标志。 (2)只用于设备文件，而不用于普通文件。

3.1.5.3、O_SYNC

(1)write阻塞等待底层完成写入才返回到应用层。 (2)无O_SYNC时write只是将内容写入底层缓冲区即可返回，然后底层（操作系统中负责实现open、write这些操作的那些代码，也包含OS中读写硬盘等底层硬件的代码）在合适的时候会将buf中的内容一次性的同步到硬盘中。这种设计是为了提升硬件操作的性能和销量，提升硬件寿命；但是有时候我们希望硬件不好等待，直接将我们的内容写入硬盘中，这时候就可以用O_SYNC标志。

3.1.6.文件读写的一些细节

3.1.6.1、errno和perror

(1)errno就是error number，意思就是错误号码。linux系统中对各种常见错误做了个编号，当函数执行错误时，函数会返回一个特定的errno编号来告诉我们这个函数到底哪里错了。 (2)errno是由OS来维护的一个全局变量，任何OS内部函数都可以通过设置errno来告诉上层调用者究竟刚才发生了一个什么错误。 (3)errno本身实质是一个int类型的数字，每个数字编号对应一种错误。当我们只看errno时只能得到一个错误编号数字（譬如-37），不适应于人看。 (4)linux系统提供了一个函数perror（意思print error），perror函数内部会读取errno并且将这个不好认的数字直接给转成对应的错误信息字符串，然后print打印出来。

3.1.6.2、read和write的count

(1)count和返回值的关系。count参数表示我们想要写或者读的字节数，返回值表示实际完成的要写或者读的字节数。实现的有可能等于想要读写的，也有可能小于（说明没完成任务） (2)count再和阻塞非阻塞结合起来，就会更加复杂。如果一个函数是阻塞式的，则我们要读取30个，结果暂时只有20个时就会被阻塞住，等待剩余的10个可以读。 (3)有时候我们写正式程序时，我们要读取或者写入的是一个很庞大的文件（譬如文件有2MB），我们不可能把count设置为2*1024*1024，而应该去把count设置为一个合适的数字（譬如2048、4096），然后通过多次读取来实现全部读完。

3.1.6.3、文件IO效率和标准IO

(1)文件IO就指的是我们当前在讲的open、close、write、read等API函数构成的一套用来读写文件的体系，这套体系可以很好的完成文件读写，但是效率并不是最高的。 (2)应用层C语言库函数提供了一些用来做文件读写的函数列表，叫标准IO。标准IO由一系列的C库函数构成（fopen、fclose、fwrite、fread），这些标准IO函数其实是由文件IO封装而来的（fopen内部其实调用的还是open，fwrite内部还是通过write来完成文件写入的）。标准IO加了封装之后主要是为了在应用层添加一个缓冲机制，这样我们通过fwrite写入的内容不是直接进入内核中的buf，而是先进入应用层标准IO库自己维护的buf中，然后标准IO库自己根据操作系统单次write的最佳count来选择好的时机来完成write到内核中的buf（内核中的buf再根据硬盘的特性来选择好的实际去最终写入硬盘中）。