Hi
On Mon, Apr 13, 2015 at 4:49 PM, Daniel Drake dr...@endlessm.com wrote:
On Sat, Apr 11, 2015 at 5:13 AM, David Herrmann dh.herrm...@gmail.com 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
On Sat, Apr 11, 2015 at 5:13 AM, David Herrmann dh.herrm...@gmail.com 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
Hi
On Tue, Apr 7, 2015 at 12:03 AM, Daniel Drake dr...@endlessm.com 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
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
