[Geany-devel] Multiple instances of Geany issues

[Lex Trotman]

On 22 May 2010 23:16, Dimitar Zhekov <hamster at mbox.contact.bg> wrote:
>
> On Sat, 22 May 2010 21:15:59 +1000
> Lex Trotman <elextr at gmail.com> wrote:
>
> > > Speaking of NFS (I read the patch) O_EXCL is problematic [...]
> >
> > Thats correct, note I used g_open which seems to say that it works under
> > windows as well. [...] the only potential problem is that it can be
> > disabled by registery settings, according to Samba documentation anyway.
>
> > > If the lock file is not successfully unlinked by Geany for some
> > > reason, for example a broken NFS connection, it'll have to be deleted
> > > manually. Well, that shoudn't be a big problem, but if there's some way
> > > to avoid it...
> > >
> > >
> > Not that I'm aware of, anybody who knows any other way that works on *ix and
> > Windows is welcome to suggest it.
>
> Both on *ix and Win~1, hmmm...
>
> It just occured to me, what if we write the configuration into
> geany-some-unique-id.conf and then g_rename() it? Rename is an atomic
> operation; on NFS, "you can not assume that if the operation failed
> the file was not renamed" - well, we can emit a geany_debug() message
> for this. Even if Win~1 g_rename() is somehow broken, a MoveFileEx (...,
> MOVEFILE_REPLACE_EXISTING) will do.
>
> We know that both entries are files, they are on the same filesystem,
> and the destination file is writable - that eliminates almost any
> possible rename error.
>
Hi,

You can get this behaviour by setting the hidden preference
use_safe_file_saving,  in that case utils_write_file uses
g_file_set_contents which does exactly what you describe, problem is
it changes owners and permissions and doesn't work on some file
systems, see thread "[Geany-devel] Safe file saving - permissions
issue" and older ones on the same topic.

Enrico still gets headaches when he thinks about that thread :-)
because the "fix" seems to require GIO which isn't available with the
oldest glib supported by Geany so it would require two file handling
codes to maintain.

Cheers
Lex

PS I figured out that the reason I got geany.conf corruption when
signalling multiple Geanys wasn't when they closed, because as you
said they don't save anything when SIGHUPed, but when the script
opened lots of Geanys, each with a project, the old session files were
being saved in geany.conf.  Still fixed by atomic write, I was going
to say unlikely in practice but of course session managers can
re-start several Geanys at once, add it to the "oh dear" list.

But OTOH I now think it unlikely that 0.19 will get problems (unless
you do extreme things like my script :-), so we are only talking about
sm versions needing the lock

>
> --
> E-gards: Jimmy
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel