:: Re: [DNG] USB mount problem
Página Inicial
Delete this message
Reply to this message
Autor: Didier Kryn
Data:  
Para: dng
Assunto: Re: [DNG] USB mount problem
Le 23/06/2021 à 11:50, Dr. Nikolaus Klepp a écrit :
> Hi!
>
> Anno domini 2021 Wed, 23 Jun 00:00:11 +0200
> Didier Kryn scripsit:
>> Le 22/06/2021 à 19:10, Steve Litt a écrit :
>> [...]
>>     Hopman-cli would write to the pipe 3 sorts of messages, with all the
>> necessary details:
>>
>> - a device special file associated to a removable partition has been
>> detected in /dev
>> - a symlink has been detected in /dev/disk/by-label, pointing to a
>> removable partition
>> - a device special file associated to a removable partition has been
>> removed
> IMO this sounds good. I would just make it react on all partitions, not only the removable: there are broken devices out in the wild that lie about their removability. And there are devices that have wrong entries in the hw database (e.g. old Casio cameras).


    No, Hopman should not show /home, /var, etc... Currently it relies
on /sys to tell which device is removable. Removable partitions might
also be declared in the config file as regular expressions.

>
> Oh, hopman would only send data, not receive from the client side, would it?
>
>> [...]
>>     Then it's up to the GUI application to
>>
>> - parse these messages, maintain and display a list of removable
>> partitions and their labels,
>> - on click, spawn helpers to mount/umount/open partitions and
>> potentially eject disks, check completion and report errors,
>> - periodically read /proc/self/mounts and report mountpoints of
>> removable partitions on the display.
> Why parse /proc/self/mounts? IMO it would make more sense if hopman-cli sends "xxxx mounted on yyy" or "xxx unlounted" over the pipe, as it is already monitoring stuff.


    There is no other way to know which partitions are mounted or not
than read /proc/self/mounts. inotify does not work on pseudo-filesystems
like /sys or /proc. Therefore, either this is done by the front-end or
by the back-end.


>
>>     Both Hopman-cli and the GUI must read hopmanrc at startup (it seems
>> simpler to have a single file to configure both). Possibly the name of
>> the GUI application might be specified in hopmanrc and Hopman-cli would
>> launch it.
> What's configurable in hopmanrc? Shouldn't it "just work" for all partitions/devices? The GUI part most likely will need some config, e.g automounting certain devices/partitions etc.


    hopmanrc provides a lot of possiblities to parameterise the
application, such as window appearance, behaviour and position, location
of pid-file and helper applications to mount/umount/open/eject
partitions/devices.

--     Didier