Hi Lars, Thanks for the information. Your guess was correct, those files had the read-only attribute set. Unsetting those attributes allowed the clearer to remove the files and top-level directory.
Thanks, Christian On Thu, Sep 12, 2019 at 1:45 PM Lars Bruun-Hansen <lbruunhan...@gmail.com> wrote: > Hi Christian > > I once wrote some notes on how the cleaner works. (yes, they are > probably worthy of a Wiki page, but currently the only exist here). It > was written about 5 years ago, but I doubt it has changed. The notes > are below and I think they are worth the read because I'm guessing > they implicitly tell you what your problem is. Here we go: > > > --- Begin notes --- > > Background > ------------------ > The "cleaner" is a small native application which is part of the > NetBeans Installer (NBI) infrastructure. The job of the cleaner is to > delete files which the JVM process for some reason cannot delete > itself. Java has its own deleteOnExit() method but that method is > pretty useless as it cannot delete files that the JVM itself uses. > Hence the idea of a cleaner. > > NBI has two cleaners: One for Linux/Mac which is a shell script and > one for Windows (cleaner.exe) which is a native image. The cleaner > gets launched from Java at the end of the NBI install/uninstall > process (from a shutdown hook). It gets launched in such a clever way > that it becomes detached from the JVM process itself, hence it will > live on even when the JVM process closes. On Unices such a process > would be known as a 'daemon' and is created by a technique called > double-fork. On Windows this is known as a 'process without handles'. > Java doesn't support spawning such a process so NBI has to rely on > native OS calls in order to create such a detached process. > > The cleaner works off a list of files to delete. It gets passed this > list of files as an argument on the command line. The list is in a > temporary file. The cleaner deletes this file after it has read it. > The list of files is supposed to be ordered so the delete happens in > the right sequence (you cannot delete a directory before you've > deleted all files in it). This ordering is done automatically by the > NBI Engine (nbi-engine.jar) so this is not something anyone creating > an installer should worry about. > > The cleaner can delete both files and directories ...if they are > empty. The cleaner has no feature for recursing through a directory > and deleting all files below it. Therefore, in order to delete a tree, > the cleaner must be told explicitly which files to delete and in which > order. > > > > How does the cleaner work on Windows ? > ------------------ > > On Windows the cleaner is a very small C program. It is (at the > moment) always 32-bit regardless of JVM or Windows version. > > After launch the cleaner will read the list of files to delete from a > temporary file. The list of files to delete is read into memory and > the cleaner can therefore delete the temporary file immediately after > it has been read. > > After reading the file list the cleaner sleeps for 2 seconds. This is > to allow the JVM process that has started it to close down. The 2 secs > are hardcoded. > > The cleaner will then loop over the list of files to delete. Each > file-delete operation is spawned into a thread of its own up to a > maximum of 64 threads. Therefore the delete operations happens in > parallel rather than in sequence. (Note: I find this design somewhat > dangerous as the order of delete can be quite important.). > > For each delete operation the cleaner will do the following: > > - Checks to see if the file exists (by getting its attributes) > - If file: delete file, if directory: delete directory (these are > two different calls in the Win32 API). > - Attempt to delete each file/dir up to 15 times sleeping for 200 > ms between each attempt. > > If there are no available threads (i.e. there more than 64 files to > delete) then the cleaner process will wait until a there are less than > 64 active threads. In other words: At any point in time there are > never more than 64 active threads. > > The cleaner process has absolutely no logging features so it is pretty > difficult so say what it does if something goes wrong. > > > --- End notes --- > > Those were my notes. > > I'm guessing the problem you see is that the cleaner cannot delete a > file with read-only attribute set. Or it is the somewhat dangerous > design of deleting files in parallel which is causing probs. I'm > leaning towards the first one. Your own guess - the two secs delay - I > don't much believe is the problem since the cleaner will attempt to > delete each file 15 times sleeping 200 ms between each attempt. > > > /Lars > > On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun <c...@oyarzun.net> wrote: > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1 > > following these instructions? > > https://dzone.com/articles/including-jre-in-nbi > > > > While this works fine under Linux , the Windows uninstaller does not > delete > > some of the JRE files. > > > > C:\Program Files\rcpapp>dir /s /b > > C:\Program Files\rcpapp\jre > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION > > C:\Program Files\rcpapp\jre\lib > > C:\Program Files\rcpapp\jre\LICENSE > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README > > C:\Program Files\rcpapp\jre\lib\cmm > > C:\Program Files\rcpapp\jre\lib\currency.data > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc > > C:\Program Files\rcpapp\jre\lib\management > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf > > C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template > > > > Any ideas on why these files are not deleted? Could it be the > INITIAL_DELAY > > is too short in the cleaner.exe? > > > > > https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561affdab8/nbi/engine/native/cleaner/windows/src/main.c#L28 > > > > Thanks, > > Christian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >