Gary, To me the guidelines are overly general for a best practice. The problem with them being overly general then the project teams will have to fight with the committees to allow an exception. Or worse the project teams will be hesitant to come to the committees to get a review because they do not adhere to this general policy. The Mozilla/Firefox example is a very good one. The lock file that you are pointing out is designed to do exactly what it is doing. It is attempting to prevent multiple copies of the tool from running. If the tool exits normally then the lock file is removed. However, if the tool is still running and the same profile is being using then it should not start another instance of itself. However, the way that the guideline is written:
> * The product shall ensure that no files exist that can prevent the > product from running (i.e., lock files, temporary files, etc.) It does not allow for such a situation. Thus no lock file or temporary file could prevent another instance of a product from running. Thanks, John On Tue, 2008-08-26 at 08:33, Gary Lengyel wrote: > > > * The product shall ensure that no files exist that can prevent the > > > product from running (i.e., lock files, temporary files, etc.) > > > > > What does this mean - products can't have lock files or other files that > > would ever stop them from running? Or that they need to make sure those > > files are all removed at some given time? (If so, when?) > > > The latter. Take Mozilla and Firefox for example. There are times when > the process(es) stop running, and a lock > file is left open. You cannot restart the application. You have to > know that its execution is being prevented > because a lock file exists (Joe user may not know that and has to log > a service desk call). This is intended to > prevent that scenario. > > When? Application startup.
