Reputation: 99478
In Unix
#include <unistd.h>
int close(int fd);
Is it correct that close(fd)
must also destroy the file table entry associated with fd
? Yes, even if there is another file descriptor referring to the same file table entry?
Does close(fd)
also destroy the vnode table entry associated with the vnode table entry, or not necessarily? Yes, even if there is another file table entry referring to the same vnode table entry?
Thanks.
For "process file descriptor table", "(kernel) file table", "vnode", see http://www.cs.rpi.edu/academics/courses/fall04/os/c18/
Note: My question comes from APUE. I am actually interested in Linux, but Linux doesn't have vnode, but general inode structure. So for "vnode" still to apply, I have to ask for Unix.
Upvotes: 1
Views: 1052
Reputation: 25286
You may assume that the following functions from the standard library: open, read, write, seek
and close
, form an interface to the operating system. In that interface it maintains some data structures. Those data structures are of no interest to the user of the standard library.
The functions mentioned do not operate on the file system. Hence no vnodes or inodes are modified by these functions. They will be operated on/modified by the filesystem part of the operating system, if such modification is required by the operations. For example, writing may require new blocks on disk to be allocated, which must be registered in an inode.
The unlink
function of the standard library instructs the operating system to remove a file. If the OS can remove the file (i.e. it is not protected, is not open by another process, etc.) it will remove the file from the filesystem, thus modifying inodes. (Filesystems with lazy deletes move the file to a recycle bin).
So: it is not correct that close(fd)
also destroys the file table entry associated with fd
, if with "file table entry" you mean the entry in the filesystem, except possibly for short lived, temporary files (however, those may never have had an entry anyway, depending on the filesystem software of the OS),
and: no, close(fd)
does not destroy "the vnode table entry associated with the vnode table entry" (which is strange sentence anyway ), if with vnode you mean some type of inode.
With reference to your course material:
Is it correct that close(fd) must also destroy the file table entry associated with fd? Yes, even if there is another file descriptor referring to the same file table entry?
No, that is not correct. close
will destroy the entry in the Process File Descriptor Table of the process. The Kernel File Table must maintain a reference count (not shown in your course material) and when that gets to zero, the entry of the KFT can be deleted. So the close
causes only the reference count in the KFT to be decremented.
Does
close(fd)
also destroy the vnode table entry associated with the vnode table entry, or not necessarily? Yes, even if there is another file table entry referring to the same vnode table entry?
I find this question not relevant or I don't understand it. There is no vnode table entry. There is only a vnode identifier in the KFT. Managing vnodes (i.e. storage allocation and deallocation) is beyond the scope of your course.
Upvotes: 2
Reputation: 215387
close
closes the file descriptor. If that descriptor is the last one referring to the corresponding open file description, then the latter will be closed, which might entail further side effects. This is in terms of the modern meaning of Unix, in terms of the Single Unix Specification/POSIX.
I'm not sure what vnode means; I assume it's part of one historical unix and has some correspondence to open file descriptions.
Upvotes: 4