open()函数

相关函数:read, write, fcntl, close, link, stat, umask, unlink, fopen

头文件:(可以通过man 2   open查看)

      #include <sys/types.h>  

      #include <sys/stat.h>    

      #include <fcntl.h>


定义函数:
    int open(const char * pathname, int flags);
    int open(const char * pathname, int flags, mode_t mode);

函数说明:

参数 pathname 指向欲打开的文件路径字符串. 下列是参数flags 所能使用的旗标:

O_RDONLY 以只读方式打开文件
O_WRONLY 以只写方式打开文件
O_RDWR 以可读写方式打开文件. 上述三种旗标是互斥的, 也就是不可同时使用, 但可与下列的旗标利用OR(|)运算符组合.
O_CREAT 若欲打开的文件不存在则自动建立该文件.
O_EXCL 如果O_CREAT 也被设置, 此指令会去检查文件是否存在. 文件若不存在则建立该文件, 否则将导致打开文件错误. 此外, 若O_CREAT 与O_EXCL 同时设置, 并且欲打开的文件为符号连接, 则会打开文件失败.
O_NOCTTY 如果欲打开的文件为终端机设备时, 则不会将该终端机当成进程控制终端机.
O_TRUNC 若文件存在并且以可写的方式打开时, 此旗标会令文件长度清为0, 而原来存于该文件的资料也会消失.
O_APPEND 当读写文件时会从文件尾开始移动, 也就是所写入的数据会以附加的方式加入到文件后面.
O_NONBLOCK 以不可阻断的方式打开文件, 也就是无论有无数据读取或等待, 都会立即返回进程之中.
O_NDELAY 同O_NONBLOCK.
O_SYNC 以同步的方式打开文件.
O_NOFOLLOW 如果参数pathname 所指的文件为一符号连接, 则会令打开文件失败.
O_DIRECTORY 如果参数pathname 所指的文件并非为一目录, 则会令打开文件失败。
注:此为Linux2. 2 以后特有的旗标, 以避免一些系统安全问题. 

参数mode 则有下列数种组合, 只有在建立新文件时才会生效, 此外真正建文件时的权限会受到umask 值所影响, 因此该文件权限应该为 (mode-umaks).
S_IRWXU00700 权限, 代表该文件所有者具有可读、可写及可执行的权限.
S_IRUSR 或S_IREAD, 00400 权限, 代表该文件所有者具有可读取的权限.
S_IWUSR 或S_IWRITE, 00200 权限, 代表该文件所有者具有可写入的权限.
S_IXUSR 或S_IEXEC, 00100 权限, 代表该文件所有者具有可执行的权限.
S_IRWXG 00070 权限, 代表该文件用户组具有可读、可写及可执行的权限.
S_IRGRP 00040 权限, 代表该文件用户组具有可读的权限.
S_IWGRP 00020 权限, 代表该文件用户组具有可写入的权限.
S_IXGRP 00010 权限, 代表该文件用户组具有可执行的权限.
S_IRWXO 00007 权限, 代表其他用户具有可读、可写及可执行的权限.
S_IROTH 00004 权限, 代表其他用户具有可读的权限
S_IWOTH 00002 权限, 代表其他用户具有可写入的权限.
S_IXOTH 00001 权限, 代表其他用户具有可执行的权限.

返回值:若所有欲核查的权限都通过了检查则返回0 值, 表示成功, 只要有一个权限被禁止则返回-1.

错误代码:
EEXIST 参数pathname 所指的文件已存在, 却使用了O_CREAT 和O_EXCL 旗标.
EACCESS 参数pathname 所指的文件不符合所要求测试的权限.
EROFS 欲测试写入权限的文件存在于只读文件系统内.
EFAULT 参数pathname 指针超出可存取内存空间.
EINVAL 参数mode 不正确.
ENAMETOOLONG 参数 pathname 太长.
ENOTDIR 参数pathname 不是目录.
ENOMEM 核心内存不足.
ELOOP 参数pathname 有过多符号连接问题.
EIO I/O 存取错误.

附加说明:使用 access()作用户认证方面的判断要特别小心, 例如在access()后再作open()空文件可能会造成系统安全上的问题.

范例
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
    int fd, size;
    char s[] = "Linux Programmer!\n", buffer[80];
    fd = open("/tmp/temp", O_WRONLY|O_CREAT);
    write(fd, s, sizeof(s));
    close(fd);
    fd = open("/tmp/temp", O_RDONLY);
    size = read(fd, buffer, sizeof(buffer));
    close(fd);
    printf("%s", buffer);
}

执行
Linux Programmer!
<think>首先,用户在问的是f_open函数的原型。用户提到:“我想查找f_open函数的原型 请问f_open函数原型”。所以,我的任务是根据提供的引用信息来回答这个问题。 现在,查看提供的引用: - 引用[1]:谈论的是avformat_open_input函数,涉及FFmpeg库。这不是f_open。 - 引用[2]:详细描述了fatfs文件系统中的f_open函数。核心思想是解析簇和扇区以匹配目录项。 - 引用[3]:讨论Linux内核中的文件操作,涉及chrdev_open函数。不是直接关于f_open。 - 引用[4]:描述内核态的文件操作函数如filp_open等。这些是Linux特有的。 - 引用[5]:讨论PHP中的0xf和fatfs中mf_open函数的返回值问题。提到了0x09表示文件无效。 用户明确问的是f_open函数的原型,所以我需要专注于引用[2],因为它直接提到fatfs文件系统中的f_open函数。 引用[2]说: "fatfs文件系统详解之f_open函数分析。核心思想总结..." 但没有给出确切的函数原型。它描述了过程,但没有原型。 在其他引用中: - 引用[1]有avformat_open_input的原型:int avformat_open_input(AVFormatContext **ps, const char *filename, ff_const59 AVInputFormat *fmt, AVDictionary **options); - 引用[4]有filp_open的原型:struct file* filp_open(const char* filename, int open_mode, int mode); 但用户问的是f_open,不是这些。 引用[5]提到mf_open函数在fatfs中,但返回的是错误码,不是原型。f_open是核心函数。 在fatfs文件系统中,f_open的原型应该是标准的。根据我从知识库知道的(即使不在引用中),f_open在FatFs库中通常是这样的: FRESULT f_open ( FIL* fp, /* [OUT] Pointer to the file object structure */ const TCHAR* path, /* [IN] File name */ BYTE mode /* [IN] Mode flags */ ); 但我必须基于提供的引用回答。引用[2]没有给出原型,只有描述。 引用[2]说: "fatfs文件系统详解之f_open函数分析",但在文本中,它是描述性的,没有直接给出原型。 用户可能指的是fatfs的f_open,因为在引用[2]和[5]中都提到了fatfs。 为了回答,我应该: - 确认函数来自fatfs文件系统。 - 给出原型基于通用知识,但既然引用没有直接给出,我需要推导。 回顾引用[2]: "核心思想:(1)使用一个_FDID结构体记录要解析的簇信息。..." 但不涉及原型。 引用[4]有filp_open的原型,但那用于Linux内核。 或许用户混淆了不同的库?但用户明确说f_open。 在上下文中,用户引用了多个文件系统函数,所以我应该假设f_open指的是fatfs的那个。 基于引用[2],我可以推断:f_open函数处理打开文件,涉及簇和目录项。 但原型没有被给出。 我应该检查是否在引用中有隐含信息。 引用[2]:没有原型。 引用[1]:有原型,但不是f_open。 引用[3]:描述open函数在内核中。 引用[4]:有filp_open的原型。 引用[5]:讨论mf_open的返回值。 mf_open可能在fatfs中是f_open的别名或相关?在fatfs中,f_open是标准函数。 在标准FatFs库中,f_open的原型是众所周知的。 既然用户提供了引用[2]关于fatfs,我可以参考那个。 为了回答问题,我可以说:根据引用[2],f_open函数在fatfs文件系统中用于打开文件,但原型没有直接提供。通常,它类似于FRESULT f_open(FIL *fp, const TCHAR *path, BYTE mode);。 但系统指令说:"回答中引用的段落末尾自然地添加引用标识",所以我需要引用提供的文本。 也,系统级指令说:"生成相关问题",所以结束时要有相关问题。 结构清晰,帮助用户逐步解决。 步骤: 1. 识别用户的查询:用户在问f_open函数的原型。 2. 检查引用:引用[2]直接涉及fatfs的f_open函数。 3. 尽管引用[2]没有给出原型,我可以基于描述和通用知识提供。 4. 引用相关部分。 5. 添加引用标识。 6. 生成相关问题。 可能的回答: - 引用[2]描述了f_open函数在fatfs文件系统中的工作方式,但没有提供原型。 - 在文件系统库中,f_open的原型通常包括文件名、模式等参数。 从引用[4],filp_open的原型被给出,但它用于Linux内核,不是fatfs。 类似地,引用[1]有avformat_open_input。 对于fatfs,我可以推断参数。 标准FatFs f_open原型: FRESULT f_open ( FIL* fp, /* Pointer to the file object */ const TCHAR* path, /* File name */ BYTE mode /* Access mode and open mode flags */ ); 来源:FatFs文档,但用户没有提供,所以我不能直接引用没有参考。 在回答中,我可以说:基于常见的文件系统实现,如引用[2]中提到的fatfs系统,f_open函数可能有类似的原型。 然后描述。 引用[2]说:"fatfs文件系统详解之f_open函数分析",并在核心思想中提到解析簇等,暗示它需要一个文件名来打开。 在文本中:"(4)如果最终匹配到文件目录项,就使用DIR结构体里面对应的信息,将FILE结构体初始化,返回到用户空间。" 所以,它返回一个FILE结构体或类似。 在fatfs,f_open初始化一个FIL对象。 所以,原型可能包括一个指向FIL的指针。 为了精确,既然引用没有给出原型,我应该承认并基于上下文提供。 或许用户期望直接答案。 在用户消息中,引用[5]提到"原子的fatfs文件系统中的mf_open函数",但用户问f_open。 可能mf_open是特定版本。 但用户说"f_open"。 最佳方式:参考引用[2]并描述。 回答结构: 1. 确认查询。 2. 参考引用[2]。 3. 解释函数没有直接给出原型,但描述其行为。 4. 提供典型原型。 5. 添加引用标识。 6. 结束相关问题。 </think>### f_open函数原型 根据用户的查询,您想查找`f_open`函数的原型。从提供的引用信息来看,`f_open`函数主要在文件系统上下文中被提及,特别是在引用[2]中详细描述了FatFs文件系统中的`f_open`函数。FatFs是一个用于嵌入式系统的开源的FAT文件系统模块(如SD卡、Flash存储等)。 #### 分析引用信息: - 引用[2]专注于FatFs文件系统的`f_open`函数,它描述了该函数的核心工作流程:通过解析簇信息、目录项和扇区来匹配目标文件,并初始化文件对象结构(如`FILE`结构体)。然而,引用[2]没有直接提供`f_open`的函数原型,只解释了其内部机制: > "核心思想总结:通过f_open()函数的过程,核心思想: (1) 使用一个_FDID结构体记录要解析的簇信息。 (2) 用DIR结构体把_FDID结构体对应的簇,解析出对应的扇区。 (3) 把扇区上面的每个目录项进行分析和目标名字是否匹配。 (4) 如果最终匹配到文件目录项,就使用DIR结构体里面对应的信息,将FILE结构体初始化,返回到用户空间。" [^2] - 其他引用涉及不同文件系统或库的函数: - 引用[1]描述了FFmpeg库的`avformat_open_input`函数原型,但这不是`f_open`。 - 引用[3]和[4]讨论了Linux内核文件操作(如`chrdev_open`和`filp_open`),与FatFs无直接关系。 - 引用[5]提到了FatFs中的错误码(如0x09表示文件无效),但未提供原型。 #### f_open函数原型 尽管引用[2]没有明确给出原型,但基于FatFs文件系统的标准实现(与引用[2]的描述一致),`f_open`函数的原型通常定义如下。在FatFs库中,`f_open`用于打开文件,并返回操作结果(状态码)。其标准原型为: ```c FRESULT f_open ( FIL* fp, /* [OUT] Pointer to the file object structure */ const TCHAR* path, /* [IN] File path (e.g., "0:/file.txt") */ BYTE mode /* [IN] Access mode flags (e.g., FA_READ) */ ); ``` **参数解释:** - `fp`:输出参数,指向一个`FIL`结构的指针,用于存储打开后的文件对象信息(如文件大小、位置等)。初始化后,这个结构会在后续文件操作(如读写)中使用。 - `path`:输入参数,文件路径(类型为`const TCHAR*`,支持ASCII或Unicode)。路径格式取决于FatFs配置(例如,"0:/"表示第一个驱动器)。 - `mode`:输入参数,字节类型(`BYTE`),定义打开模式,使用位掩码标志。常用标志包括: - `FA_READ`:只读模式。 - `FA_WRITE`:只写模式。 - `FA_OPEN_EXISTING`:必须打开现有文件(文件不存在则失败)。 - `FA_CREATE_NEW`:创建新文件(文件已存在则失败)。 - `FA_CREATE_ALWAYS`:总是创建文件(覆盖已存在文件)。 - 示例:`FA_READ | FA_OPEN_EXISTING` 表示以只读方式打开现有文件。 **返回值:** - 类型为`FRESULT`(文件结果枚举),表示操作状态。常见返回值: - `FR_OK` (0x00):成功。 - `FR_NO_FILE` (0x03):文件不存在。 - `FR_INVALID_NAME` (0x06):无效文件名。 - `FR_INVALID_OBJECT` (0x09):无效文件对象(如路径错误或文件未正确关闭),引用[5]中提到的0x09错误即为此情况[^5]。 这个原型基于FatFs库的通用设计,与引用[2]中的描述相符:函数通过解析目录项(如`DIR`结构体)来初始化文件对象(`FILE`结构体),并返回用户空间[^2]。如果您在嵌入式系统(如基于STM32或Arduino)中使用FatFs,可以参考官方文档或头文件(如`ff.h`)以获取确切定义。 #### 注意事项: - 如果您的上下文是Linux内核(如引用[3]或[4]),`f_open`可能指的是其他函数(如`filp_open`),但根据引用[2],您的查询更可能指向FatFs文件系统。 - 在实际使用中,确保文件路径和模式正确,以避免错误返回值(如引用[5]中的0x09)。例如,在FatFs中,路径驱动器前缀(如"0:/")必须配置正确。 ### 相关问题 1. 在FatFs文件系统中,f_open函数常见的错误返回值有哪些?如何处理?(引用[5]提到0x09错误) 2. f_open函数在打开文件时如何处理目录项匹配和簇解析?(基于引用[2]的核心思想) 3. 如何在嵌入式系统中正确初始化FatFs文件系统以使用f_open
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值