Unioning file systems: Architecture, features, and design choices
Posted Jan 15, 2013 15:15 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
That's why I said »assumption«, not »guarantee«. It is clear that it is possible to stipulate cases where if you remove a file, another one will immediately pop up in its place – and it is also clear that one shouldn't write programs based on the idea that just because a file was removed just now, another one of the same name cannot have appeared in the meantime.
However, if – like most of the people most of the time – you're just working away in your shell somewhere below $HOME, that sort of thing is highly unlikely. In that context, chances are that if you just removed a file you'd expect it to be gone, not replaced by some older or default version. For example, I often do something like »rm *~« in order to clean up before, e.g., making a tar file, and I don't want this to unearth random files from the layer below.
The other problem is that with this approach it is impossible to make files go away completely if they exist in a read-only layer. This can be a hassle for programs that assume certain defaults if they don't have a certain configuration file. If somebody in your virtualisation base image helpfully supplied a configuration file you don't want, either you're in luck because the program doesn't mind an empty configuration file that you put on top, or else you will have to come up with one that undoes just the stuff you don't want because you can't get rid of the unwanted file altogether.
to post comments)