使用stat()获取文件类型的替代方法?

另一种选择是 fstat() 如果您已经打开了文件(因此您有一个文件描述符)。或 lstat() 如果您想了解符号链接,而不是符号链接指向的文件。

我认为手册页夸大了成本;它并不比任何其他必须将文件名解析为inode的系统调用差多少。它比 getpid() ;它比 open() .

“文件类型” stat() 给出的是文件是常规文件还是设备文件或目录之类的文件,以及它的大小和inode号等。如果这是你需要知道的,那么你必须使用 状态() .

如果你真正需要知道的是文件的类型 内容 --例如,文本文件、JPEG图像、MP3音频—然后有两个选项。您可以根据文件扩展名猜测(如果文件扩展名以“.mp3”结尾,则该文件可能包含mp3音频),也可以使用 libmagic ,它实际上会打开文件并读取其中的一些内容以确定它是什么。libmagic方法更昂贵(如果您试图避免 状态() ,你可能想避免 open() 但不太容易出错(例如,.mp3文件实际上是一个jpeg图像)。

在具有某些文件系统的Linux下,文件类型(常规、字符设备、块设备、目录、管道、符号链接,…)存储在Linux目录结构中,这是内核通过getdents系统调用提供的应用程序目录项。如果stat结构中唯一需要的是文件类型,并且需要为一个目录的所有或多个条目获取该文件类型,则可以直接使用getdents(而不是readdir)并尝试从中获取该文件类型,只有在Linux中发现无效的文件类型时才使用statNT。根据应用程序的文件系统使用模式,如果使用Linux,这可能比使用stat快,但是stat在许多情况下应该快。

stat的速度主要与定位磁盘上请求的数据有关。如果您递归地遍历一个目录来stat所有的文件,那么每个stat都应该以相当快的速度结束,因为获得stat所需的数据的大部分工作都是在您通过先前的stat调用向内核请求之前缓存的。在系统中随机分布的文件数,那么内核可能必须从磁盘中读取要调用stat的每个文件的几个目录。

fstat应该总是非常快,因为内核应该已经有了您在ram中请求的数据,因为它需要访问它才能使文件处于打开状态,并且内核不必费劲地遍历文件名的路径来查看每个组件是否在ram中或在ram上磁盘,可能从磁盘读取目录(但可能不需要),结果发现它有您在ram中要求的数据。

也就是说,在打开的文件上调用stat应该比在未打开的文件上调用stat快。

你知道*nix系统上的“魔法”文件吗?通过从命令行查询文件 file myfile.ext 你可以得到真正的文件类型。

这是通过读取文件的内容而不是查看其扩展名来完成的,并且在*nix(linux,unix,…)系统上广泛使用。

如果您的应用程序需要在linux系统上运行,为什么不尝试inotify(7)。它绝对比 stat 有很多文件。