Hello!

Still able to reproduce the issue, and definitely willing to test it, given
a binary. As of writing, compiling it myself isn't feasible though.

Also, is there a reasonable chance that the write succeeds after a
> smaller delay than 1 second? For example, might we want to try again
> after 0.25 seconds for the first time, 0.5 seconds after the second, 1
> second after the third, and then stay at 1 second for the fourth, fifth,
> and sixth try? I can update the patch, if this change would be desired.
> I have no intuition for the cost of trying more frequently, so I don't
> have a strong opinion.


It would probably suffice to remove the temporary file, once the "Retry"
succeeds. Currently, even the "Retry" leaves the temporary file; Presumably
the "Retry" creates a second temporary file and forgets about the first one.

- Klaus

On Wed, Aug 8, 2018 at 5:38 AM Richard Kimberly Heck <rikih...@lyx.org>
wrote:

> On 08/07/2018 07:13 PM, Scott Kostyshak wrote:
> > The following issue seems to affect a lot of users:
> >
> >   https://www.lyx.org/trac/ticket/10091
> >
> > Riki posted a patch (see comment 42), but from what I can tell it has
> > not had any testing on Windows since no one who can reproduce the issue
> > can also compile on Windows.
> >
> > It seems that the risk to including the patch is that it does not fix
> > the issue and actually makes the issue worse by introducing a 5 second
> > delay. However, perhaps that risk is worth it.
> >
> > Riki, can you provide the commands that I need to make a test binary for
> > Windows users? This way I can try to save you some time from creating it
> > yourself since you have already done so much. Well, actually it might
> > take you more time to explain to me how to do it, but I would volunteer
> > to make test binaries for Windows users in the future.
>
> Yes, I am thinking it might take more time to explain it. The code is
> currenty in a
> branch in my developers' repo. I'll put it into 2.3.x at some point
> soon, and then others
> will be able to use it.
>
> Riki
>
>

Reply via email to