:: Re: [DNG] Hopman (Was: ..are we|Dev…
Top Page
Delete this message
Reply to this message
Author: aitor
To: dng
Subject: Re: [DNG] Hopman (Was: ..are we|Devuan safe from this systemd backdoor malware (...)?
Hi again Didier,

On 3/5/21 11:53, Didier Kryn wrote:
>     I'm very happy that you cath up on Hopman. I initially made it for
> my needs and the community and as a proof of concept. Then I became too
> ambitious and I didn't succeed to properly organize internationalization
> files and I got discouraged. Yet the tool is working and it is my only
> installed tool to mount hotplug USB disks.

I had a copy of your code, but i lost the part dedicated to the
It doesn't worry me because my approach in dealing with this matter will
differ a bit from yours.
However, i would like to verify i'm using your most recent code of
Hopman anyway,
and the gitlab repository, annoucced on the other hand in Emiliano
Marini's website [*], no longer exists:

https://git.devuan.org/kryn/hopman <https://git.devuan.org/kryn/hopman>

>     The first method I considered to determine which device was
> hotpluggable was a config file made of a list of regular expressions to
> match the device file names, such as "sd[c-f]*", untill I found that
> kernel tag. Then I discovered, like you, that it only tagged USB
> devices. But I sticked with the kernel tag by lazzyness and beause I
> could live with it (I use an USB-SDcard adapter).

With the inclusion of some files taken from the vdev project, the device
file names
are no longer a problem to worry about. However, you'll be still able to
list all the hotpluggable devices via:

$ lsblk -o PATH,HOTPLUG

The only requirement is util-linux. At  this point, as you already know,
it's worth to highlight that *hotpluggable* is not the same as
*removable*. *


>     There is still a bug in a function in subdir watch, which I have
> narrowed down to a logic error in the handling of multiple inotify
> events in one buffer. This happens typically the first time a loop
> device is mounted, because the driver then creates all loop devices at
> once and the corresponding inotify events are small enough that more
> than one can fit in the buffer; then hopman enters an endless loop.
> Maybe I will dedicate time to repair it some day (~:

I'm not using inotify, but there is still an issue related to the use of
lstat in the following file:


only when you leave running hopman for an overly long time (which isn't
the case in practice),
because of the many opened files during the recursive scanning of

To end with, i've just updated the code in gitea including a screenshot,
and let's say that it's working pretty fine:


Btw, i added a reference in the headers of my files, and also included
myself in the LICENSE file.
The same with the code taken from vdev, mantaining Jude Nelson's
copyright there. Is it right?



[*] Aka linuxito: