If someone downgrades, everything will still work fine, but lots of exe-username-MD5-asdfasdfasdf files will be left behind. The admin can safely remove all of them without harm! Of course, no one would ever downgrade Condor.
+If an exe-username-MD5-asdfasdfasdf file is erroneously deleted, the system keeps working. Duplicate copies of the file may later be made, but existing jobs will never notice. (Removing the ickpt file for a given job will break it, but that's the existing situation.)
+
We're not going to tackle the issue of sharing sandboxes (input and output files) in the spool. There are many complications there: sandbox files can change, necessitating some sort of copy on write system; sandbox ownership changes over time based on the state of jobs. This might be useful future work, but it's a massive task.
By "link" we mean a hard link. On most Unix like systems, we're talking about link(). On Windows, we're talking about {link: http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx CreateHardLink()}.
@@ -174,7 +176,7 @@
*: We can hard code to prepend "exe-$EscapedOwner" to the list of "things". This means the filename is an exact match for the CmdHash value, simplifying queries mapping jobs to files and vice versa. This might make life a bit easier for admins. It will also simplify garbage collection of unused files.
-*: We may someday stop having ickpt files (see "Future work" above). If the user can change his own CmdHash, we'll lose track of his ickpt file. This isn't serius; we'll eventually reclaim it on a garbage collection pass, but it does at least temporarily waste disk space.
+*: We may someday stop having ickpt files (see "Future work" above). If the user can change his own CmdHash, we'll lose track of his ickpt file. This isn't serious; we'll eventually reclaim it on a garbage collection pass, but it does at least temporarily waste disk space.
Cons:
