在Unix中
#include <unistd.h>
int close(int fd);
close(fd)还必须销毁与fd关联的文件表条目是否正确？是的，即使还有另一个文件描述符引用相同的文件表条目？
close(fd)是否还会销毁与vnode表条目关联的vnode表条目？是的，即使还有另一个文件表条目引用相同的vnode表条目？
谢谢。
有关“进程文件描述符表”，“（内核）文件表”，“ vnode”，请参见http://www.cs.rpi.edu/academics/courses/fall04/os/c18/
注意：我的问题来自APUE。我实际上对Linux感兴趣，但是Linux没有vnode，而是通用的inode结构。所以对于“ vnode”仍然适用，我必须要求使用Unix。
答案 0 :(得分：4)
close关闭文件描述符。如果该描述符是引用相应打开文件描述的最后一个描述符，则后者将被关闭，这可能会带来进一步的副作用。这是根据Unix的现代含义，即Single Unix Specification / POSIX。
我不确定vnode是什么意思；我认为它是一个历史Unix的一部分，并且与打开文件的描述有些对应。
答案 1 :(得分：2)
您可以假定标准库中的以下功能：open, read, write, seek和close，构成了操作系统的接口。在该接口中，它维护一些数据结构。这些数据结构对于标准库的用户来说并不重要。
提到的功能在文件系统上不起作用。因此，这些功能不会修改vnode或inode。如果操作需要对它们进行修改，它们将在操作系统的文件系统部分上进行操作/进行修改。例如，写操作可能需要在磁盘上分配新块，这些新块必须在inode中注册。
标准库的unlink函数指示操作系统删除文件。如果操作系统可以删除文件（即不受保护，未被其他进程打开等），它将从文件系统中删除文件，从而修改inode。 （具有延迟删除功能的文件系统会将文件移动到回收站。）
所以：close(fd)也会破坏与fd关联的文件表条目是不是正确的，如果使用“文件表条目”则表示文件系统中的条目，但可能只存在短暂的临时文件（但是，这些文件可能永远都不会有条目，具体取决于操作系统的文件系统软件）
and：不，close(fd)不会 not 销毁“与vnode表条目相关联的vnode表条目”（无论如何这都是很奇怪的句子），如果与vnode一起意味着某种类型的索引节点。
参考您的课程材料：
close（fd）还必须销毁与fd相关联的文件表条目是否正确？是的，即使还有另一个文件描述符引用相同的文件表条目？
不，那是不正确的。 close将破坏进程的进程文件描述符表中的条目。内核文件表必须维护一个参考计数（课程资料中未显示），当该参考计数变为零时，可以删除KFT的条目。因此close仅会使KFT中的引用计数递减。
close(fd)是否还会销毁与vnode表条目关联的vnode表条目？是的，即使还有另一个文件表条目引用相同的vnode表条目？
我发现此问题不相关或不理解。没有vnode表条目。 KFT中只有一个vnode标识符。管理vnode（即存储分配和释放）超出了您的课程范围。