One way to address this would simply be to require use of a urlBaseId and to generate a unique one every time a file is regenerated. This would result in a unique entry in the files table.

I agree it's not hard to figure out how to represent such a repeatedly-rewritten file in the run.files dictionary. The problem this scenario raises is how a viewer can present the various incarnations of the file, when only the most recent one actually exists on disk. I need to know more about how tools use these repeatedly-rewritten files. For example: if a tool scans version 1 of such a file, finds a result, rewrites the file, rescans it, and finds a second result, what's the viewer to do when the user double-clicks on the first result?

@michaelcfanning @kupsch Jim, was this your issue originally, or was it Paul's? Please see my comment/question above... is there really anything we can do about this?

Fixed by 0401f51.