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 > >
