[oi-dev] More on USB failure to automount

[Andreas Wacknitz]

> Am 10.10.2021 um 21:43 schrieb Gary Mills <gary_mills at fastmail.fm>:
>
> On Sun, Oct 10, 2021 at 10:33:07AM +0200, Andreas Wacknitz wrote:
>>
>> Hi, are there any news about this bug and its fix?
>
> That patch didn't work.  Neither did the next dozen or so.  However, I
> did learn a great deal about glib.  I know what the cause is.  I just
> don't have the solution yet.
>
> One of the causes is the nature of the EAGAIN error.  In the context
> of hald and glib on OI, the read() system call within glib produces
> this error when the pipe is empty, but the other end of the pipe is
> still open for write.  Every subsequent read() will produce the same
> error until the process at the other end actually writes something to
> the pipe.  This error is converted to G_IO_STATUS_AGAIN by glib.  hald
> only processes lines when the status returned by
> g_io_channel_read_line() is G_IO_STATUS_NORMAL .  It ignores any
> others, including G_IO_STATUS_AGAIN .
>
> The other cause is that lines written by hald (with the write() system
> call) to the pipe all end with "\n\0".  Yes, the trailing null is
> written to and read back from the pipe.  However, hald does not set
> the line terminator as glib expects, instead relying on glib's
> automatic line ending determination.  In this case, that appears not
> to work.  Instead, glib does a second read, which always sets the
> status to G_IO_STATUS_AGAIN .  Once set, this status replaces any
> previous status.
>
> As you can see, hald writes lines to the pipe with write() but reads
> them back with g_io_channel_read_line().  That design may be a third
> cause.
>
> I'm going to do a bit more testing with hald and glib, and then return
> to what I was doing with OI.
>
>

Thank your for your update and good luck on your way of fixing this issue.

Andreas