[At_Libitum]

I can see where the idea comes from. Using one big container file with it's own internal 'filesystem' was/is still used for a lot of games. and most of these games also got released on several platforms. So in that respect the idea is not that strange. The only thing that is different here, the dynamic nature of a library compared to the static environment of game resources. You'd have to go the direction of virtual hd files or something similar and let the current rdbms use the container file to write-to/read-from instead of trying to recreate the rdbms. But...like physical hd's, virtual file systems tend to get fragmented the same way, with the same side effects. Which means, reorganization is needed, which means needing at least as much free diskspace as the size of the container file, preferable double that.

It may look like a good idea, but it has one helluva drawback. If something, how small even, breaks in the container file, it's bye-bye- library. At least in the current situation, all books stay intact. Which means you probably want to maintain some kind of parity system for repairs if worst comes to worst. In the end, the risk some mishap occurring to a virtual file system is much higher than to a physical one. Files get damaged much more often than HD's