0

From APUE

#include <unistd.h>
int unlink(const char *pathname);

Only when the link count reaches 0 can the contents of the file be deleted. One other condition prevents the contents of a file from being deleted: as long as some process has the file open, its contents will not be deleted. When a file is closed, the kernel first checks the count of the number of processes that have the file open. If this count has reached 0, the kernel then checks the link count; if it is 0, the file’s contents are deleted.

  1. If a file is being used by execve() in a process, does it count it as "the process has the file open"?

  2. If some process has the file being open or execve()ed, will unlink() immediately return 0 or -1, or wait till the process closes the file or execve() finishes running and performs its job?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Tim
  • 1
  • 141
  • 372
  • 590
  • 1
    Remember to account for the O_CLOEXEC flag to [`open()`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html), and the `FD_CLOEXEC` option to [`fcntl()`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html). – Jonathan Leffler Jun 09 '18 at 21:56
  • 1
    Possible duplicate of [What happens to an open file handle on Linux if the pointed file gets moved, delete](https://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handle-on-linux-if-the-pointed-file-gets-moved-del) – Zan Lynx Jun 09 '18 at 23:04
  • A process is a process. In what way doesn't your quotation answer your question entirely? – user207421 Jun 10 '18 at 04:43

2 Answers2

7

1) The file handles inherited by processes via execve will remain open until explicitly closed or the process exits.

2) unlink will not block. It will simply remove the path and decrement the reference count of the hard-linked file, at which point the filesystem may remove the referenced file and free the space associated with it once the file is no longer opened by any process. unlink will return 0 unless there was an I/O or permissions error, etc.

jspcal
  • 50,847
  • 7
  • 72
  • 76
  • 1
    Thanks. "The file handles inherited by processes via execve ", but `execve()` unlike `open()` doesn't return a file handle – Tim Jun 09 '18 at 23:25
  • The spawned process inherits the file handle table of the original process. – jspcal Jun 09 '18 at 23:28
  • But `execve()` doesn't return a file handle – Tim Jun 09 '18 at 23:29
  • 1
    On success, `execve` does *not* return. The currently executing program is replaced with a new one. – jspcal Jun 09 '18 at 23:37
3

For a file which is execve-d or mmap-ed, the kernel also considers that (inside the kernel) the file descriptor is used (so the kernel inode has a refcount which is positive). See also inode(7) and proc(5). Notice the ETXTBSY error code in errno(3). An executable could even remove itself during execution (see this and that) and the file's inode remains until the process is terminated or does some other execve.

Hence the data inside such as file is not released (until the execve or mmap is inactivated)

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547