Saturday, March 3, 2007

ASP.NET temporary directory cleanups

In the past weeks I've committed several changes in order to make the ASP.NET temporary directory a bit less of a space hog for those who restart their xsp/mod_mono often.
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 way the XXs, YYs and VVs above are generated is that the XXs are a hexadecimal hash of the assembly name (sans the path) - it groups files of the same name in the same subdirectory. VVs are hexadecimal hash of the assembly path (sans the name). YYs are an XOR of XXs and VVs.
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: