mjhjmtu

In FreeBSD, man mount_nullfs states that:

The primary differences between a virtual copy of the file system and a
symbolic link are that the getcwd(3) functions work correctly in the virtual
copy, and that other file systems may be mounted on the virtual copy
without affecting the original. A different device number for the virtual
copy is returned by stat(2), but in other respects it is indistinguishable
from the original.

What is the full meaning/implication of this paragraph?

The primary differences between a virtual copy of the file system and a
symbolic link are that the getcwd(3) functions work correctly in the virtual
copy,

getcwd’s behaviour with symlinked directories is a fairly well-known gotcha, documented in Advanced Unix Programming for example (see this SO question for a quote): chdir and getcwd aren’t symmetric when symlinks are involved. One might expect that changing directories, using chdir, to a given directory, and then retrieving the current directory, using getcwd, would return the same value; but that’s not the case when a process changes directory using a path containing a symbolic link — getcwd returns the path obtained after de-referencing all symbolic link(s). This can have unexpected consequences when changing directories to a parent directory, when the path containing symbolic link(s) and the de-referenced path have different numbers of components.

and that other file systems may be mounted on the virtual copy
without affecting the original.

Continuing Stéphane’s example, you can mount another file system on a sub-directory of /tmp/b without affecting /some/dir, whereas mounting a file system on a sub-directory of /tmp/a will make it show up under /some/dir too.

A different device number for the virtual
copy is returned by stat(2), but in other respects it is indistinguishable
from the original.

This means that running stat on the copy, or any file thereunder, will return a different device number compared to the original, but that’s the only difference; apart from that, stat("/tmp/b/c", &buf) and stat("/some/dir/c", &buf) would return the same information.

I think they mean that if /tmp/a is a symlink to /some/dir and /tmp/b is a nullfs mount of /some/dir,

• after chdir("/tmp/a"), getcwd() returns /some/dir.


• after chdir("/tmp/b"), getcwd() returns /tmp/b.

It's not that much that the former is incorrect. It's just that symlinks and nullfs mounts have two different semantics.

A symlink is a pointer to another file which most system calls (including chdir()) follow, while a nullfs mount makes a whole directory tree available under a different path (and contrary to Linux' similar bind-mounting feature or directory hard links in some other systems, the files there appear as being different files).

The symlink handling can break some people expectations (like that getcwd() here), but nullfs mounts (or the bindfs fuse filesystem on Linux or some union filesystems) can break other people expectations like the fact [ /tmp/b/x -ef /some/dir/x ] would return false even though they are the same file underneath, or that fuser /tmp/b/x could return nothing even when there are processes that have it opened via the /some/dir/x path.

The Linux bind-mounts (which do not make the files appear as being different) could break some other people expectations, like find -xdev/du -x traversing the mount point, two links to the same file with a link-count of 1 (it also allows loops to be created in the filesystem; FreeBSD's nullfs guards against that).

Hard links (the oldest of those technologies that make files appear under different paths) as well can break some users expectations (like that when you unlink a file from a directory, you expect it to no longer be available).

So I wouldn't say that one is more correct than the other here.