Open lukebakken opened 2 months ago
fhsc
can continue being an optional dependency that, unlike handle.exe
is open source and can produce easier to parse output (JSON).
handle.exe
will then be deprecatedfshc
will eventually become the only optionOr, for 4.1.0
, we can stop supporting handle.exe
since it is optional already, and
move straight to using fshc
's JSON output.
Right now the biggest item left is a an Actions workflow that would produce 64-bit builds of fshc
for Windows, Linux and macOS (the latter two for anyone who may need it, not for RabbitMQ's own needs).
For what it's worth, handle.exe
(or Windows in general) requires administrator privileges to list file and socket handles and information, as described in the "Installation" section of the documentation.
Notice the difference:
In both sessions I started C:\Windows\System32\handle64.exe -nobanner | more
.
I'm unsure why the notice is logged when RabbitMq runs as Local System and starts / spawns handle.exe
. Maybe someone can catch that using ProcMon :)
IMO as of 1.2.0
, fshc
is ready to be integrated.
handle.exe
does not reliably produce parsable output. On top of that, it is closed source abandonware.We should replace it with a small open source alternative our team members have developed as a personal project.
Some things involved
fshc.exe
.fshc.exe
executable.Migration Strategies
fhsc
can continue being an optional dependency that, unlikehandle.exe
is open source and can produce easier to parse output (JSON).handle.exe
will then be deprecatedfshc
will eventually become the only optionOr, for
4.1.0
or4.2.0
, we can stop supportinghandle.exe
since it is optional already, and move straight to usingfshc
's JSON output.Right now the biggest item left is a an Actions workflow that would produce 64-bit builds of
fshc
for Windows, Linux and macOS (the latter two for anyone who may need it, not for RabbitMQ's own needs).References