Le 25/04/2019 à 01:17, Didier Kryn a écrit :
> Le 24/04/2019 à 20:43, Steve Litt a écrit :
>> On Wed, 24 Apr 2019 09:05:12 +0200
>> Didier Kryn <kryn@???> wrote:
>>
>>> Le 24/04/2019 à 01:05, Evilham via Dng a écrit :
>>>> Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt
>>
>>>> 3. Document the misbehaviour when users... Misbehave (okay, that
>>>> was a bad joke).
>>>       There's an infinite number of ways a human can misbehave. For
>>> brutal extraction of the media, I don't think it is easy to
>>> characterize.
>> There's a way. There can be a "superumount" that acquires a root
>> password and keeps doing umount until it's really unmounted on all
>> lists like mtab.

    Here is what happens when a mounted filesystem is physically
removed while mounted :

    It is still listed as a mountpoint in /proc/self/mountinfo,
although the device-file of the partition has been removed.

    At this point, if the mountpoint is not in use in any process,
pumount unmounts it without error and deletes the mountpoint, but it
must be done from the command line because hopman doesn't show the
partition anymore. If pumount reports an error it is because some
process is using this mountpoint, eg a terminal-emulator or a file-manager.

    Suppose the device-file of the partition was sdb1. If you re-insert
the device, it will be named sdc1, because the kernel still has sdb1
mounted.

    If one wants to perform cleanup, meaning unmounting automatically
the partitions which have been removed, this can be done by a daemon
watching /dev. But a policy should be defined about the processes using
the mountpoints. Some of these processes may have chances to get IO
errors, but some don't perform any IO to their current working
directory. Should they be all killed ? What is going to happen to them
if umount() is invoked with the MNT_FORCE flag? That's kind of pulling
the carpet under their feet.

        Didier

        Didier