On 22 May 2010 23:16, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Sat, 22 May 2010 21:15:59 +1000 Lex Trotman elextr@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel