Unioning file systems: Architecture, features, and design choices
Posted Jan 15, 2013 13:55 UTC (Tue) by anselm
In reply to: Unioning file systems: Architecture, features, and design choices
Parent article: Unioning file systems: Architecture, features, and design choices
The first time you invoke it, rm /c/x chases the link to /a, because x is present there, and removes /a/x; the second time, it removes /b/x.
That's the obvious way of handling this. It does break the (reasonable) assumption that after a successful rm(1) of a file that file will be gone (in the sense of »open("/c/x", O_RDONLY) fails«), rather than replaced by the next one over.
One of the main goals of a union filesystem (or equivalent), in my opinion, is that the files and directories it presents behave as nearly like ones on a non-union filesystem as possible. From that point of view the »paths in links« approach is a complete non-starter.
to post comments)