The old implementation used to generate random file/directory names for both per-application toplevel temporary directory and all the files below it (including shadow files which can occupy a lot of space on larger sites). The changes I made include, so far, the following:
- Generate a toplevel temporary directory with predictable name. The hash calculation is based on the virtual and the physical paths of the application.
- The shadow files no longer have fully randomized names (of the form shadow-XXXXX with the Xs being replaced by hex characters), instead they are put in a subdirectory of the temporary directory named assembly/shadow/XXXXXXXX/YYYYYYYY_VVVVVVVV/ which is different for every shadow-copied assembly.
The above scheme tries to mimic what MS .Net runtime does (except they use
dl3
instead of shadow
in the above path), but I can't guarantee that the hashes are computed the same way they do. The way we do it guarantees that no two different assemblies can end up in the same shadow directory and create a name clash - that's sufficient.The new shadow scheme uses considerably less space, which is very good, and it also adds another benefit - the .mdb (debug data) and .config files that accompany the original assembly are copied together with the assembly.
The remaining temporary directory cleanup issue is how we should remove the old assemblies. If anyone has any information about how MS .Net does that (I haven't investigated the issue yet) - please let me know.
No comments:
Post a Comment