Unioning file systems: Architecture, features, and design choices
Unioning file systems: Architecture, features, and design choices
Posted Jan 15, 2013 15:00 UTC (Tue) by hummassa (subscriber, #307)In reply to: Unioning file systems: Architecture, features, and design choices by nix
Parent article: Unioning file systems: Architecture, features, and design choices
Exactly what it does in the case of a union fs: removes all files, recursively, from the "top" filesystem (the "bottom" filesystems are read-only), refusing to remove any files present in the "bottom" filesystems.
> A really nasty question is what wildcard expansion does: what does /c/f* do if there are files matching f* in both /a and /b? As far as I can see, the semantics sunburnt described do not allow for the obvious semantics (expand files in /a and /b) without less-than-obvious changes to every program that does globbing and fnmatching everywhere -- and without those changes, the semantics you seem likely to get are quite bizarre.
Again, no nasty question: /c/f* will bring all files that match in the union /c, i.e., a merge with of /a/f* and /b/f*. A file called f1 present both in /a and in /b will come only once, referring obviously to /a/f1.
Posted Jan 15, 2013 23:50 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Unioning file systems: Architecture, features, and design choices