test case: mkfifo p df p
That hangs, unless you make "p" non-readable or some other process has the fifo open in write mode. The reason is that df tries to open the fifo in read-only mode, according to comments in the source code so as to trigger a potential automout. That goes back to this commit: > commit dbd17157d7e693b8de9737f802db0e235ff5a3e6 > Author: Tomas Smetana <[email protected]> > Date: Tue Apr 28 11:21:49 2009 +0200 > > df: use open(2), not stat, to trigger automounting > > * src/df.c (main): When iterating over command-line arguments, > attempting to ensure each backing file system is mounted, use > open, not stat. stat is no longer sufficient to trigger > automounting, in some cases. Based on a suggestion from Ian Kent. > More details in http://bugzilla.redhat.com/497830 More info at the bugzilla link. It's arguable whether df, a reporting tool, should have such a side effect as automounting a file system. The fifo issue though is a bug IMO, especially considering that POSIX explicitely says that df should work on fifos. Here, it may be enough to add the O_DIRECTORY flag to open() where available if we only care about automounting files of type directory (or portably use opendir()). Or use O_PATH on Linux 3.6+ followed by openat() on non-fifos if open(O_PATH) is not enough to trigger the automount in the unlikely event we care about automounting non-directory files (and report their disk usage). Or not open() at all, and not automount file systems. Note that busybox, heirloom or ast-open df implementations on Linux don't have the problem (and presumably don't automount file systems). Nor does FreeBSD. Reproduced with: $ df --version df (GNU coreutils) 8.25 and: $ df --version df (GNU coreutils) 8.27.46-e13fe That was discovered by Martijn Dekker, CCed, when looking for a portable way to identify the file system of an arbitrary file. -- Stephane
