操作文件,除了上述C接口(当然,C++也有接口,其他语言也有),我们还可以采用系统接口来进行文件访问,先来直接以代码的形式,实现和上面一模一样的代码
pathname: 要打开或创建的目标文件
flags(标志位): 打开文件时,可以传入多个参数选项,用下面的一个或者多个常量进行“或”运算,构成flags。
参数:
O_RDONLY: 只读打开
O_WRONLY: 只写打开
O_RDWR : 读,写打开
这三个常量,必须指定一个且只能指定一个
O_CREAT : 若文件不存在,则创建它。需要使用mode选项,来指明新文件的访问权限
O_APPEND: 追加写
返回值:
成功:新打开的文件描述符
失败:-1
mode_t理解:直接 man 手册,比什么都清楚。
open 函数具体使用哪个,和具体应用场景相关,如目标文件不存在,需要open创建,则第三个参数表示创建文件
的默认权限,否则,使用两个参数的open。
在认识返回值之前,先来认识一下两个概念: 系统调用 和 库函数
上面的 fopen fclose fread fwrite 都是C标准库当中的函数,我们称之为库函数(libc)。
回忆一下我们讲操作系统概念时,画的一张图
系统调用接口和库函数的关系,一目了然。
所以,可以认为,f#系列的函数,都是对系统调用的封装,方便二次开发
通过对open函数的学习,我们知道了文件描述符就是一个小整数
那么怎么解释呢?
直接看代码
输出发现是 fd: 3
关闭0或者2,在看
发现是结果是: fd: 0 或者 fd 2 可见,文件描述符的分配规则:在files_struct数组当中,找到当前没有被使用的最小的一个下标,作为新的文件描述符
那如果关闭1呢?看代码:
此时,我们发现,本来应该输出到显示器上的内容,输出到了文件 myfile 当中,其中,fd=1。这种现象叫做输出重定向。常见的重定向有:>, >>, <
那重定向的本质是什么呢?
1和2都是往显示器上打印,那么他们有什么不同呢?
显示器刷新方式是行缓冲,而其他文件的刷新方式是全缓冲
我们提前将1关闭,打开了一个新文件,根据文件描述符分配规则,这个文件的fd就是1,那么刷新方式也就有行缓冲变为了全缓冲,如果我们没有提前关闭fd,那么程序退出数据就会自动从C缓冲区刷新到OS缓冲区中,也就会在文件中看到hello world,但是此时如果我们提前将fd关闭,那么就不会刷新到文件中,也就不会看到hello world
这是因为显示器的刷新策略是行刷新,在我们关闭标准输出的时候数据已经由C缓冲区刷新到OS缓冲区了,所以我们会在屏幕上看到打印的三条消息,但是我们重定向到文件当中的时候,刷新策略由行缓冲变为了全缓冲,再关闭标准输出,所以数据就不会刷新到OS缓冲区中,也就不会在文件中看到hello world,但是为什么可以在文件中看到hello标准输出呢?因为write是系统调用接口,直接就会写入到OS缓冲区。
如果有兴趣,可以看看FILE结构体
typedef struct _IO_FILE FILE; 在/usr/include/stdio.h
在/usr/include/libio.h
struct _IO_FILE {
int _flags; /* High-order word is _IO_MAGIC; rest is flags. */
#define _IO_file_flags _flags
//缓冲区相关
/* The following pointers correspond to the C++ streambuf protocol. */
/* Note: Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
char* _IO_read_ptr; /* Current read pointer */
char* _IO_read_end; /* End of get area. */
char* _IO_read_base; /* Start of putback+get area. */
char* _IO_write_base; /* Start of put area. */
char* _IO_write_ptr; /* Current put pointer. */
char* _IO_write_end; /* End of put area. */
char* _IO_buf_base; /* Start of reserve area. */
char* _IO_buf_end; /* End of reserve area. */
/* The following fields are used to support backing up and undo. */
char *_IO_save_base; /* Pointer to start of non-current get area. */
char *_IO_backup_base; /* Pointer to first valid character of backup area */
char *_IO_save_end; /* Pointer to end of non-current get area. */
struct _IO_marker *_markers;
struct _IO_FILE *_chain;
int _fileno; //封装的文件描述符
#if 0
int _blksize;
#else
int _flags2;
#endif
_IO_off_t _old_offset; /* This used to be _offset but it's too small. */
#define __HAVE_COLUMN /* temporary */
/* 1+column number of pbase(); 0 is unknown. */
unsigned short _cur_column;
signed char _vtable_offset;
char _shortbuf[1];
/* char* _save_gptr; char* _save_egptr; */
_IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};
我们使用ls -l的时候看到的除了看到文件名,还看到了文件元数据
每行包含7列:
为了能解释清楚inode我们先简单了解一下文件系统
Linux ext2文件系统,上图为磁盘文件系统图(内核内存映像肯定有所不同),磁盘是典型的块设备,硬盘分区被划分为一个个的block。一个block的大小是由格式化的时候确定的,并且不可以更改。例如mke2fs的-b选项可以设定block大小为1024、2048或4096字节。而上图中启动块(Boot Block)的大小是确定的,
将属性和数据分开存放的想法看起来很简单,但实际上是如何工作的呢?我们通过touch一个新文件来看看如何工作
目录也是文件,那么目录里面存放的是什么呢?文件名:inode编号
创建一个新文件主要有一下4个操作:
我们看到,真正找到磁盘上文件的并不是文件名,而是inode。 其实在linux中可以让多个文件名对应于同一个inode。
硬链接本质上不是一个独立的文件,而是一个文件名和inode编号的映射关系,因为自己没有独立的inode。
我们在删除文件时干了两件事情:1.在目录中将对应的记录删除,2.将硬连接数-1,如果为0,则将对应的磁盘释放
硬链接是通过inode引用另外一个文件,软链接是通过名字引用另外一个文件,在shell中的做法
acm
下面解释一下文件的三个时间
动态库(.so):程序在运行的时候才去链接动态库的代码,多个程序共享使用库的代码。
动态库和静态库本质上都是文件。库文件的名字:lib.xxx.so或则lib.yyy.a-…库的真是名称去掉lib前缀,去掉.a- .so剩下的就是库的名称。
在可执行文件开始运行以前,外部函数的机器码由操作系统从磁盘上的该动态库中复制到内存中,这个过程称为动态链接(dynamic linking)
动态库可以在多个程序间共享,所以动态链接使得可执行文件更小,节省了磁盘空间。操作系统采用虚拟内存机制允许物理内存中的一份动态库被要用到该库的所有进程共用,节省了内存和磁盘空间
这样我们的源文件也会被其他人看见,所以我们可以生成静态库
-I:指明头文件搜素路径
-L:指明库文件搜素路径
-l:指明要链接哪一个库
那么我们用的系统的库,为什么不用带这些选项呢?之前的库,在系统的默认路径下(/usr/bin,、lib64, /usr/include)编译器是能够识别这些路径的
如果我们也想不用带选项,也可以将对应的库和头文件拷贝到默认路径下,但是严重不推荐
别人也可以使用Makefile编译
1、拷贝.so文件到系统共享库路径下, 一般指/usr/lib(不建议)
如果只提供静态库,我们只能将我们的库,静态链接到我们的程序中
如果只提供动态库,我们只能将我们的库,动态链接到我们的程序中
如果既然需要动态链接又需要静态链接,就提供两种版本的库。(gcc和g++优先链接动态库)