0

How well does bindfs behave, when the user makes some modification to the lower directory directly (i.e. not through bindfs) ?

(Motivation: I assumed that it would not be a good idea to wrap a directory with bindfs, at a time when that directory was being written to. But it made me curious.

In theory I'd also be interested if there was an answer for another FUSE filesystem or one based on general FUSE principles, but I can't think of a good way to ask that here).


Kernel bind mounts - mount --bind - share the VFS cache in some way. That is an example where concurrent modifications are fully supported, as far as I know.

An example where modifying a backing filesystem is not supported at all is the kernel overlayfs filesystem.

Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.

sourcejedi
  • 50,249

1 Answers1

0

It looks like there are less issues with this for bindfs, than there are for overlayfs.

It basically implies there is full support, except for some limitation of MacFuse.

MacFuse caches file contents by default. This means that changes in source files are not always immediately visible under the mount point. -o nolocalcaches can be used to disable the cache.

https://bindfs.org/docs/bindfs.1.html

I strongly suspect this is neglecting to mention something, because there is also a cache for file attributes (e.g. permissions). FUSE also caches directory lookups. That said, the default lifetime of these caches on FUSE, e.g. attr_timeout, seems to be very short e.g. 1 second.

sourcejedi
  • 50,249