Hi
On Mon, Apr 13, 2015 at 4:49 PM, Daniel Drake wrote:
> On Sat, Apr 11, 2015 at 5:13 AM, David Herrmann wrote:
>> Nice catch!
>>
>> There's indeed a small race between handling inotify and queuing up
>> the change-event. We need to re-loop there. One day we should switch
>> to sd-event to avoi
On Sat, Apr 11, 2015 at 5:13 AM, David Herrmann wrote:
> Nice catch!
>
> There's indeed a small race between handling inotify and queuing up
> the change-event. We need to re-loop there. One day we should switch
> to sd-event to avoid such bugs... I mean the symptom is inherent to
> queuing up eve
Hi
On Tue, Apr 7, 2015 at 12:03 AM, Daniel Drake wrote:
> udev uses inotify to implement a scheme where when the user closes
> a writable device node, a change uevent is forcefully generated.
> In the case of block devices, it actually requests a partition rescan.
>
> This currently can't be sync
udev uses inotify to implement a scheme where when the user closes
a writable device node, a change uevent is forcefully generated.
In the case of block devices, it actually requests a partition rescan.
This currently can't be synchronized with "udevadm settle", i.e. this
is not reliable in a scri
