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
