@jksoegaard I’m intrigued. What’s the firmlink implementation you mentioned in comments. I’d love to learn more and comments seems less ideal than chat to learn that.

@bmike You can just google the names I gave, I think they're pretty unique. In generic terms the feature is known as union file systems, file system layering or file system stacking.

If you look at for example overlayfs, it is built directly into the Linux kernel

It's not a new thing. Linux has had those types of unioning file systems for 15+ years. In the old days it was mainly used to enable booting from a read-only CD-ROM overlayed with a writable filesystem (usually in RAM).

@jksoegaard thanks for the extra notes. Overlayfs confused me since it literally allows for two files in the same path and resolved to the superior copy. It seems more like copy on write or a frozen filesystem that unravels all modifications every reboot.

I will dig some more on the other terms to see which behave like two way traversal between different file systems.

I know HURD had a firmlink server process, but don’t know much other than a cursory search and no actual experience or look at the source code...

@bmike It's not copy-on-write, nor does it necessarily unravel on reboot.

debian.org/ports/hurd/hurd-doc-server#firmlink

If you place the upper file system in RAM-disk, and do not backup it - then ofcourse it is gone when you reboot. In all other instances, the changes are persisted.

No, the overlay can be thought of as similar to, not implemented that way (necessarily)

Why do you want to "think of it" differently... i.e. what do you think is the fundamental difference between firmlinks and this?

Firmlinks are a bit "lighter" to setup, as they don't require a line in a seperate configuration file for each junction point... but apart from that, it's very much the same conceptually.

Apple's firmlinks are not the same as the ones in HURD, as HURD's firmlinks are path-baed (like symlinks) - but Apple's are not.

I.e. on HURD a firmlink between /myfiles and /usbdrive would translate accesses on /myfiles/test.doc to /usbdrive/test.doc as a path. If you connect an external drive on /usbdrive on Monday, the firmlink points to files on that external drive. If you then disconnect that on Tuesday and mount a different drive on the same path, then the firmlinks points to file on that drive.

On Catalina that's not the case. If you replace the drive, the firmlinks will stop working

(in addition to the fact that you can't really create firmlinks yourself ofcourse, but I guess that's a temporary restriction)

Yeah. I think Apple is keeping it very basic to start. Leveraging just a small portion of the capabilities for very specific special cased scenarios. I wouldn’t be surprised if much was hard coded and they’re still waiting on API and implementation details knowing they will change.

Seems to be that way certainly.. for example if you look at /usr/share/firmlinks you have the beginnings of a configuration file (somewhat similar to unionfs) - but you cannot edit it and change how it works