Thank you guys for your replies. And thanks Jochen for asking about what is not clear. I didn't want to give more detail initially to not make my message too long.
My Groovy script runs within a Java application (called OmegaT). This application extends its functionality by loading the jar files it finds in the /plugins folder of the installation. Even though they are optional and added/removed on demand, once the application runs, the jar files are loaded and become part of the running code that is being executed just as the code base of the application itself. My script downloads those jar files for the user and puts them in the /plugins folder. However, as there are updates in the jar files (and new versions normally have a different name), my script needs not only to download (and overwrite) the new ones but also delete the old ones. That's because, even though I'd think it should be easy for the application to sort what it finds and pick the one with the latest version number, in practice it seems that's not so easy -- the developers say the loading order is not guaranteed (it's up to the classpath loader to determine which one is used). To avoid that the application uses an old jar file instead of the new one, they should be deleted (i.e. my script's job). Now, why are they (normally) locked? I guess it is because the application loads them and opens them all when it is launched. So, even though one version only is used in the end (if the application can see that they are different versions of the same plugin and picks only one), it seems all the jar files in the folder are (normally) loaded and locked. Which is, I think, what you mean in your last paragraph. And your conclusion might be, unfortunately, correct. I had a hope that someone here could suggest a creative alternative. Either that, or the dirty hack I mentioned. Thanks. Cheers, Manuel Jochen Theodorou <blackd...@gmx.org> escreveu no dia segunda, 7/09/2020 à(s) 13:04: > Hi Manuel, > > I must say, I find this all a little bit confusing. > > True certainly is that Java has a general problem with keeping files > open on the windows platform, if these are kept open by some objects. > ClassLoaders keeping jars open is a prime example for this and was > reason for a many bug reports throughout the lifetime of Java. Mapped > File in NIO surely is another culprit. Which is not because of Java per > se, it is the combination of Windows in general not allowing delete open > files (saved one or two users from deleting their windows directories) > and Java's memory management. > > But I wonder what actually is keeping your files open in your example. > Because those jars you download, they are not used by a class loader, > are they? And I also do not see much NIO magic applied here. > > Your program seems to delete old versions of jars (which supposedly > fails), download the new versions and is then done. The jar files are > not opened, are they? Then why should deleting them be blocked by that > program? > > Of course if there is an actual application involved, which actually > loads those jars, then there is imho no solution in this without > cumbersome changes in the application itself. > > bye Jochen > > On 07.09.20 10:41, Manuel Souto Pico wrote: > > Hi there again, > > > > Unfortunately the suggested solution --method deleteOnExit()-- didn't > > really help. I thought it was working but for some reason the files I > > had to delete were not locked at that particular moment. Maybe because > > the Java application had been running but idle for some time... I don't > > know, the lock (or the lock release) seems to happen a bit randomly. > > > > In any case, I'm still looking for a good workaround. > > > > In the absence of anything better, I will use ByteArrayOutputStream, as > > I explained in my original message, to deplete the locked files > > (deleting their contents) and then kill the application and run a > > post-processing bat script that deletes empty files. I know this is a > > hack, but I don't see how else I can do this. > > > > Tips welcome. > > > > Cheers, Manuel > > > > Manuel Souto Pico <terminola...@gmail.com > > <mailto:terminola...@gmail.com>> escreveu no dia domingo, 6/09/2020 à(s) > > 23:01: > > > > Thank you so much, J. David. > > > > Your suggestion works like a charm. Really grateful for that, and > > really glad I asked in this list :-) > > > > I will update the Stackoverflow page. > > > > Have a great day. > > Cheers, Manuel > > > > J. David Beutel <l...@getsu.com <mailto:l...@getsu.com>> escreveu no > > dia domingo, 6/09/2020 à(s) 22:37: > > > > Hi Manuel, > > > > I don't know if this would work, but have you tried > > File.deleteOnExit()? > > > > Cheers, > > 11011011 > > > > > > On 2020-09-06 08:26 , Manuel Souto Pico wrote: > > > Hi there, > > > > > > This is my first message to this list. > > > > > > I am a translator who writes scripts in groovy every now and > > then to > > > automate some tasks, although I'm not really a programmer. > > > > > > I have written a script that downloads some plugins (jar > > files) and > > > the script runs within the Java environment that uses those > > plugins. > > > The script must download the latest version of the plugin, > > > overwrite it if it already exists locally and delete any other > > > (earlier) versions of the same plugin. > > > > > > For example, the script downloads remote > > > file plugin-omt-package-1.6.3.jar from a certain URL, and > > must delete, > > > say, existing local file plugin-omt-package-1.6.2.jar. > > > > > > The problem: > > > > > > However, existing local files are locked by my Java > application > > > (within which the groovy script runs) so the script doesn't > > delete > > > them. Apparently there is a bug on Windows (not on Linux) > > which is why > > > a Java application cannot easily release the lock. > > > > > > Somebody explains the bug in this thread > > > > > > https://stackoverflow.com/questions/4179145/release-java-file-lock-in-windows/48489019#48489019 > > > > > > I have followed the suggestion in that page and tried to > > > use ByteArrayOutputStream in my delete_other_versions > function: > > > > > > ByteArrayOutputStream bos = new ByteArrayOutputStream(0); > > > FileOutputStream fos = new FileOutputStream( new > > File(path_to_file) ); > > > bos.writeTo(fos); > > > fos.close(); > > > > > > System.gc() > > > file.delete() // me beating about the bush > > > > > > My full code is here: > > > > > > https://gist.github.com/msoutopico/7b2b340e9cec830f4b2ce207575e7525 > > > > > > That seems to delete the content of the files (I can see they > > have now > > > a size of 0 kb), but not the files themselves. > > > > > > I would be grateful for further suggestions for workarounds > > about ways > > > I could manage to delete them. > > > > > > Thanks in advance. > > > > > > Cheers, Manuel > > > > > > > > > >
