Java SE 1.5 and earlier (1.6 provides additional methods but GlassFish cannot assume 1.6 is present) does not provide a platform-independent way to protect files from deletion and then unprotect them again.
There is the File.setReadOnly() method but there is no counterpart (again, in 1.5 or earlier) to set a file back to read/write. The ACC could create a new OS process and use platform-specific command syntax to accomplish this but my feeling at the moment is that this would be overkill since this is the first time I've heard of this problem.
Because the ACC expands the generated app client JAR (and any embedded submodules) into temporary directories, it would not seem practical to open a channel to each of the files so expanded in order to establish OS-level locks on them to prevent deletion while the client is running. (Locking directories would not be sufficient since the classes and other files within those directories could still be deleted, causing the trouble you have reported.) That could easily exhaust the open file limit and would further slow down the client start-up.
And, the way the class loader works is that it does open a channel to each file for the duration of the run. Instead, it opens one long enough to read the information from the .class (or other resource) file and then closes it, again to economize on OS resource usage.
As for tracking down the responsible program, you might consider FileMon (
http://www.microsoft.com/technet/sysinternals/utilities/filemon.mspx) which I have not used myself but looks like it might help with this detective work. Its features seem to have been folded into the recently-enhanced ProcessMonitor (
http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx). I have not used it either.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=231613