Cascade File System or thoughts on the file system of my dreams

We are all accustomed to the standard vision of file systems that have long been established: there is a mount point, and the node tree grows from it. It is convenient, familiar to everyone and tested for decades. But what if there are several of these points?

I would like to offer you my concept of how I see it. So far, unfortunately, in theory, since I do not have sufficient knowledge of the design of file systems, but I am more than sure that there are plenty of people at Habré, and my goal is to encourage them to constructive criticism and discussion of the idea I proposed.

What is it all for?

Once I was sitting on Windows intravenously and the chances that after installing the program it can be removed and the system does not have any remnants of it left, they tended to zero, just remember the system32 folder and the dll-horror happening there. Then I moved to Mac OS X, where most of the programs are installed by simply copying the * .app folder to myself. But it turned out to be not so simple, programs still wrote to the Library, as well as other system folders. And what if it would be possible to "mount" programs to the file system, thereby creating a sandbox for them from which they could not get out? You unmount one such image - and absolutely all the files created by this program would be removed from the system. But not everything is so simple.
')

What about the others?

I was guided to the idea of ​​a cascading file system by the structure of packages in languages ​​like Java.
For example, we have an application consisting of 3 jar libraries:



As a result, our application is a collection of all classes of all libraries, which are perceived as one. At the same time conflicts are resolved by imposition.

Conflicts

Perhaps the main problem of this approach is how to resolve conflicts when a file is present in two or more images. So far, the only adequate solution I can offer is the priority linear hierarchy of mount points (where the 0th position provides the highest priority)
Due to this, the file search algorithm becomes trivial: try to take a file from the first image in the list, if it is not there - repeat the operation for the next one. On the application side there should be a mechanism for rearranging the priorities of the images.
For obvious reasons, the first image must be an operating system image. This will make it impossible to simply override the system file from an image with a lower priority. Also, in theory, this will allow reinstalling the OS by simply shifting the image of the new OS to the zero position.

Out of the sandbox

But the application does not always have to work in its sandbox, it is not rare that they need to exit it to modify system files or to obtain elevated privileges. To do this, you can use the standard system of privileges users to write to the "alien" images.

Benefits

As I have already said, one of the main advantages is the impossibility of the program without the explicit permission to keep files behind it. Also, user data could be completely separate, and you can either take everything with your own hands or create a backup, or delete it without fear that something will be forgotten (for example, when you quit your job)

Conclusion

I do not pretend to the genius of the decision and I myself see in it no less cons than pluses, but I would like to hear exactly your opinion and not carry this thought in my head. As a programmer, I always try to separate monolithic structures into components, and the file system with which I have to work every day, I just could not ignore :)

PS As always, comments on the spelling and stylistics of the text, please write in private messages, not in comments. Thank.

UPD: pawnhearts user provided a link to ru.wikipedia.org/wiki/UnionFS . His google is stronger than mine :)