#7 Reload File Crashes Geany

[Sean]

I am using Geany 0.5 on Ubuntu Breezy. Very frequently
while using Geany, I will get "The file 'datetest.php'
on the disk is more recent than the current buffer. Do
you want to reload it?" There is no possibility that
this file has been changed on the disk, and it shows no
bias between files opened on the local disk or the
network. Also, if I click "Yes" to reload the file,
Geany crashes every time. If I say "No" to reload,
everything is fine, but typically in a matter of
minutes Geany will tell me the file needs to be loaded
again.

[Sean]

Logged In: YES
user_id=1457986

$ geany

(geany:9032): GLib-GObject-CRITICAL **: g_object_unref:
assertion `G_IS_OBJECT (object)' failed
Segmentation fault

This is what the console says after the crash, I also
noticed that Geany will crash when I manually tell the file
to reload and click 'Yes'.

[Enrico Tröger]

Logged In: YES
user_id=1117045

The crash while reloading files is fixed in CVS. Sorry for
that. ;-)
What do you mean with "Very frequently"? Where is the file
located, local, or some kind of mounted network filesystem
or is this file inside a FAT filesystem? I guess, the
filesystem where the file is located, doesn't support
modification time. This is the value, which is used by Geany
to detect whether a file was changed.
Answer here, post on the mailing list or send directly a
mail to me.

[insta]

Logged In: YES
user_id=1465172

I have the same problem. From what I can gather, the
problem exists because Geany checks the file modification
date against the local system time. If the file is stored
on a network mount where there is clock skew, it will always
report the files as being modified.

[Sean]

Logged In: YES
user_id=1457986

Thanks for the reply, eht16, I moved to the CVS version and
reloading does not crash Geany anymore. However, it does
seem to happen pretty frequently still. I think cities-insta
may be on to something.

[Enrico Tröger]

Logged In: YES
user_id=1117045

Yes, the problem is the check for the modification time. A
simple alternative is the file size, this should be a bit
better, because it is also equal on different file systems.
But this check fails, if someone altered the file but the
size didn't change. I will think about it.
Btw: at the moment the CVS version could be a bit buggy
because of many new features, so don't hit me ;-).

[insta]

Logged In: YES
user_id=1465172

In digging through the code (what bit I can decipher: I'm
not a C programmer), I notice you have an array of currently
open files. Why not store the last modification time as a
separate variable in the struct whenever the file is
(re)loaded, and then check that number against the
last-modified variable returned from stat?

So, rather than the code saying "does the return value from
stat() indicate a different time than the system clock", you
can check if the return value from stat() indicates a
different value than open_files[idx].first_mod_time.

That way, problems with clock skews will be avoided because
you'll always use the host filesystem for the modified
information, and you can rely on the generally more-accurate
"last modified" timestamp versus a potentially inaccurate
filesize differential.

[Enrico Tröger]

Logged In: YES
user_id=1117045

Fixed in the way you descibed. I hope it works, please test it.