IMHO this is quite useless, Trylon - if we control the client (as we will in open source Uru), we make it downloading the latest updates, save these checksums, and send those to the server - while we actually use a different set of files. That might even be possible with the closed client and some wrapper between the client and the OS (like wine is one). There is no way to prevent the client from not loading what the server serves if we control the client. We have to trust the user not to maliciously modify the client, and harden the server to make sure that a malformed client can not do any permanent damage to the vault or the age state (in an ideal world, we might even limit the impact to the client only, but the way Uru works, it's almot impossible to stop one client from crashing another).
However, a whitelist like I implemented it with UruStarter still has the advantage to prevent accidental modifications, which also happens frequently. Plus, it allows an admin to rename a pak file if he sees fitting
. However, the check has to be done in the game engine binary itself, or it is rendered useless by per-process file system virtualisation like Vista and above use it (that "roaming" technology to keep old applications working, even though they save their config in the program directory). UruStarter is as good as we can get without touching the sources.
So, what I would do would be very similar to the UU dataserver, but the client would always fetch the whole dataserver information on startup (we can still let it decide whether it actually updates the ages before linking there) and remove all files not mentioned there - since MOUL puts all the settings and KI images and so on in "Documents", that is perfectly safe. Ok, the Jalak column states also have to be moved there.