[Geany-devel] Multiple instances of Geany issues

Lex Trotman elextr at xxxxx
Mon May 24 04:33:26 UTC 2010

On 24 May 2010 01:04, Dimitar Zhekov <hamster at mbox.contact.bg> wrote:
> On Sun, 23 May 2010 08:04:33 +1000
> Lex Trotman <elextr at gmail.com> wrote:
>> 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.
> Not exactly. geany.conf is a special case: it's more important to make
> sure that it is consistent than that it is saved.

Don't quite understand what you mean by this, I was just noting that
your implementation is available already via an option and noting some
reported issues with it.

If there were no reported issues then it would be fine to use, but
since there are issues I wouldn't want to enforce use of this method.

As of the
> permissions, do we support such thing as "shared configuration
> directory"? If not, they won't be an issue either.

I'm not sure if its explicitly supported or prohibited, I think its
not thought about before, but it is possible, so someone will do it :)
plus project files are not in the config directory so they are more
likely to be relevant.

>> 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.
> Both the g_open() used by you, and g_rename(), exist since 2.6; the
> documentation says they are wrappers for the respective POSIX
> functions. Personally I'd expect that the support for open(O_EXCL) is
> worse that rename(), the latter being also an ANSI function.

Both are documented as working and I can't find any recent reports of
problems, note that exclusive access is the default in the windows
CreateFile() call used by windows open()

>> [...]
>> 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
> I think so too, and my X sm is raceless, so..

Answered in the other thread, this one is intended to be for sm-less
version to see what might be needed for 0.19 release.  I'm presuming
that one or other sm version will make it into 0.20 so we don't need
to finalise that quickly.

> Can anyone please test if Windows waits for the WM_QUIT message to be
> processed before sending a WM_QUIT to another program on logout?
> Just open 2 Geany-s, modify a file in both of them and logout. If the
> "Do you want to save?" messages are displayed one by one, we'd better
> drop the locking/renaming at all, it has too many potential problems.

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

To summarise I propose that the only changes that need to be suggested
for 0.19 are:

* preference dialog preferences but not session preferences are saved
when the dialog is closed and not when Geany is closed.

*  --new-instance instances should not save the geany.conf on close
but the main instance should save the session part without modifying
the dialog prefs part.

These are usage issues not race issues, with this change
--new-instances won't upset the main session but any instance can set
the preferences and whichever set them last will be the ones used when
starting any new Geanys.

Post 0.19 perhaps the preferences dialog could have a reload button to
allow multiple instances to re-sync with the saved prefs or it could
even be auto if geany.conf was monitored.

Saving of projects in --new-instances has benefits both ways, so I
suggest leaving it as is for now (ie does save).

Your patches save-settings-fix and save-filelist-fix do this fine so I
suggest to Enrico/Nick that they should be part of 0.19.


More information about the Devel mailing list