A file opened for read and write can be unlinked

Question

In my program (on Mac OS X), I opened the file using following code.

 int fd;
 fd = open(filename, O_RDWR);

Program to delete the file is as follows:

unlink(filename);

In my case, I have same file which is opened and deleted. I observed the following:

1. After opening the file, I can delete it using this program and even by using rm command.
2. After deleting the file, read and write operations are working on the file without any problem.

I would like to know the reason behind this. How to prevent rm command or unlink(2) system call from deleting the file which is being opened?

Answer 1

You can't stop unlink(2) from unlinking a file which it has permission to unlink (i.e. it has write access to the directory).

unlink is not called unlink because nobody could think of a better name. It's called that because that is what it does; it unlinks the file from the directory. (A directory is just a collection of links; i.e. it associates names with the location of the corresponding data.) It does not delete the file; the file is garbage collected by the filesystem when there are no longer any links to it.

Open file descriptors are not the only way to keep links to files. Another, quite common, way is to use the link(1) command without the -s option. This creates "hard" links. If a file has several hard links, then removing one of the links (with unlink(2)) does just that -- it removes one of the links.

The rm command has a possibly more confusing name, but it, too, only removes the name, not the file. The file exists as long as someone has a link to it, including a running process.

Answer 2

First, rm command is calling unlink(2)

Then, unlinking an opened file is a normal thing to do on Linux or others Unixes (e.g. MacOSX). It is the canonical way to get temporary files (like tmpfile(3) probably does).

You should understand what inodes are, and realize that a file is not its name or file path, but essentially an inode. A file can have zero, one, or several file paths or names (one can add more with the link(2) syscall, provided all the names sit in the same filesystem). Directory entries associate names to inodes.

So there is no (POSIX-ly portable) way to prohibit I/O on open-ed files without any names. For some opened file, the kernel has reference counters to its inode, and keep that inode till all processes having open(2)-ed it did close(2) it or have terminated.

See also inode(7) and credentials(7).

Answer 3

It's a normal Situation in UNIX SYSTEM. when you rm or unlink an opened file. UNIX system just mark a flag , and won't really delete the file desception. until the file is closed. and it will be really deleted in the file system.

It's protection to help the daemon work fine.