Re: [Flightgear-devel] Windows nav-cache permission issue

[Edward d'A. <tru...@gm...>]

On Monday, 27 February 2017, James Turner <zak...@ma...> wrote:

> Hi,
>
> Had a bit of insight on the commonly reported failures on the forum about
> the Nav-cache being read-only. It looks as if the whole nav-cache thing may
> have been completely mis-leading - the problem is nothing to do with the
> nav-cache at all, it’s unfortunate that the error mentioned it, since that
> has rather distracted from finding the solution. (All of the above assuming
> we have found the solution, which is still uncertain but looking quite
> likely).
>
> The actual problem seems to be the fgfs.pid file we use to ensure only one
> copy of FGFS is running with write-access to FG_HOME - all other copies run
> with read-only access. On POSIX I use standard open+unlink behaviour to
> create the PID file but ensure we don’t ever get stale ones, even if the
> system crashes. I then used Google / StackOverflow to find equivalent code
> for Windows - CreateFile with a ‘delete file on close’ flag. However, it
> looks as if this behaviour may be fragile in the case of non-clean exits /
> power-offs. I’ve just pushed a patch to next to change to a
> named-mutex-based solution on Windows (POSIX is unchanged), which can’t
> ever get stuck with stale data, since there is no file at all.
>
> The reason I think this may be the culprit:
>
>  - the affected FG_HOMEs I’ve been sent contain a fgfs.pid
>  - none of the error output that would indicate a problem opening the
> cache file is produced, suggesting the Sqlite startup is running on its
> normal codepath, not some error path
>  - in the case of a read-only home, we *don’t* log to fgfs.log (so once
> there is a bad fgfs.pid, we don’t see any useful logging at all)
>
> This still doesn’t entirely make sense, because for example while
> developing on Windows I kill the application all the time while developing
> and don’t see a stale fgfs.pid : so the file-based approach must work some
> of the time. But switching to the named mutex seems like a pragmatic
> solution, given the amount of pain this issue causes.
>
> My intention is to let this bake on the nightlies for a few days, and once
> it’s confirmed as working there, merge to the release branch.
>
> Did I mention I hate Windows? :)


Windows probably hates you too ;)  For the archives, the two relevant forum
threads are:

    https://forum.flightgear.org/viewtopic.php?t=31746
    https://forum.flightgear.org/viewtopic.php?t=31720

Note that forum user commsbiff partly confirmed the zombie fgfs.pid file
being the issue and SkinnierSteve fully confirmed it.  A few more tests on
fresh $FG_HOME's with navigation cache errors after an upgrade should
confirm this without doubt.

Cheers,

Edward