in some cases, Geany doesn't detect file has been overwritten. If a file with the same name is (intentionally) copied from a different directory, Geany doesn't detect the file has changed.
This does not reproduce when the file is copied using `cp`. I've only tested with the 2 file managers listed below.
* To reproduce
Reproduces every time using Thunar 1.8.4 and PCMan 1.3.1
echo file1 > ./file1 mkdir tempdir echo file2 > tempdir/file1
Open ./file1 in Geany Use Thunar or PCMan to copy tempdir/file1 to ./file1 Switch back to Geany (note there will be no reload option).
``` 16:56:32: Geany INFO : Geany 1.35 (git >= b8cdfddf), en_US.utf8 16:56:32: Geany INFO : GTK 3.24.5, GLib 2.58.3 16:56:32: Geany INFO : System data dir: /home/andy/local/share/geany 16:56:32: Geany INFO : User config dir: /home/andy/.config/geany 16:56:32: Geany INFO : Loaded GTK+ CSS theme '/home/andy/local/share/geany/geany.css' 16:56:32: Geany INFO : Loaded GTK+ CSS theme '/home/andy/local/share/geany/geany-3.20.css' 16:56:32: Geany INFO : System plugin path: /home/andy/local/lib/geany 16:56:32: Geany INFO : Added filetype Clojure (61). 16:56:32: Geany INFO : Added filetype Graphviz (62). 16:56:32: Geany INFO : Added filetype CUDA (63). 16:56:32: Geany INFO : Added filetype JSON (64). 16:56:32: Geany INFO : Added filetype Arduino (65). 16:56:32: Geany INFO : Added filetype Scala (66). 16:56:32: Geany INFO : Added filetype Genie (67). 16:56:32: Geany INFO : Added filetype Cython (68). 16:56:32: Geany INFO : Loaded libvte from libvte-2.91.so 16:56:32: Geany INFO : /home/andy/temp : None (UTF-8) 16:56:32: Geany INFO : /home/andy/file1 : None (UTF-8)
```
I can reproduce on Windows 10 using Windows Explorer as file manager.
``` Geany 1.34, English_Canada.1252 GTK 2.24.32, GLib 2.58.1 ```
Works for me Mint 19.1 Nemo 4.06 (fork of Nautilus 3.4 without the functional downgrades of 3.6) and works with cp on the command line.
08:23:22: Geany INFO : Geany 1.35 (git >= c4f5878d), en_AU.UTF-8 08:23:22: Geany INFO : GTK 3.22.30, GLib 2.56.3
@andy5995 @codebrainz Please show date/time of `file1` and `temp/file1` before and `file1` after the copy.
Oooops didn't provide the date times, and have deleted the the files, for me the date/time of `file1` after the copy is the same as `temp/file1` not what it was before the copy.
It works if I as expected if I zip the source file and extract it over the destination file. I believe this is a trick to get windows to keep the source file time(s).
Pcmanfm 1.2.5 WFM @andy5995 maybe its something you have set?
@codebrainz yeah, if Windows explorer does not change the modified date/time then Geany won't see the change.
Pcmanfm 1.2.5 WFM @andy5995 maybe its something you have set?
Nothing related to time in the settings.
Ok, so after I try it with PCManfm changing reversing the dates, I get the reload indicator if ./tempdir/file1 is more recent than ./file1 (and ./file1 is open in Geany).
But I think in most cases, ./file1 would be more recent. If someone is editing the file and saves it, it would always be more recent. But at some point if he wants to overwrite that file with an original copy (from a different directory) that's slightly different than the one being edited, Geany won't recognize the change. i.e. ./file1 will always be more recent than the original.
[Edit: I should point out that this is Geany's expected behaviour]
Hmmm... ok. I didn't realize that. When I discovered this bu.. feature, I was doing some game-modding and needed to replace some opened files with their originals (from a different directory). I kept wondering why the change wasn't having any effect. Maybe a more alert person would have immediately realized the problem and just closed and reopened the file. ;)
The additional problem I'm noticing now is when I overwrite the more recent one (open in Geany) with the older duplicate, and then tell Geany to open the file, no change shows at all, unless I close the open file first and re-open it.
But if you're sure this is all the expected desired behavior then this ticket can be closed.
I get the reload indicator if ./tempdir/file1 is more recent than ./file1 (and ./file1 is open in Geany).
Isn't that the situation with your reproduce instructions in the OP, `temp/file1` is created after `./file1`? Which is why it worked for me.
If its the other way around and the file manager copies the date/time from the older file to the newer file during a copy then yes there is no prompt because [the compare](https://github.com/geany/geany/blob/11436f58defe5312c4d6eec1225868c5dca585e4...) is `<` not just `!=`. Its been that way for at least the 10 years I looked back before I got bored. And the info message does say "file on disk is newer" so I would say its intentional, the code is looking for a file that has been modified after it was last saved, so its mtime should be newer.
File managers backdating the modification time on changed files is a "bad thing" because if it does that to a source code file then `make` will break when next run :cry: .
Plain `cp` of course sets the mtime to now, not the from file time, when it does the copy so you get the message.
The additional problem I'm noticing now is when I overwrite the more recent one (open in Geany) with the older duplicate, and then tell Geany to open the file, no change shows at all, unless I close the open file first and re-open it.
How are you telling Geany to open the file? If you want to get on-disk contents just reload.
File managers backdating the modification time on changed files is a "bad thing"
Naw, it's technically the "right thing". mtime is only updated when the contents are changed. When you copy and overwrite/paste a file in a file manager, you're essentially deleting the destination file, and putting the copied file in its place. Since the pasted file's contents never changed, there's technically no reason to update the mtime. What Geany should probably do is use the ctime, which covers both the contents and metadata.
Naw, it's technically the "right thing". mtime is only updated when the contents are changed. When you copy and overwrite/paste a file in a file manager, you're essentially deleting the destination file, and putting the copied file in its place.
Yeah, the file mangler is __replacing__ the file, in fact mine even says "do you want to replace" in its dialog :)
Geany is checking for a file having its contents changed, not the file itself being replaced.
What Geany should probably do is use the ctime, which covers both the contents and metadata.
But st_ctime doesn't cover a file having its contents changed "The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.)" (from `man 7 inode`).
And on Windows [IIGC](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functi...) st_ctime is creation time not metadata time.
I am not sure why Geany doesn't test equals which would handle both.
But st_ctime doesn't cover a file having its contents changed
Dunno, just went by some [random website](https://www.unixtutorial.org/atime-ctime-mtime-in-unix-filesystems), I didn't test it.
Geany is checking for a file having its contents changed, not the file itself being replaced.
It would be useful to detect the metadata changes too. For example if you make a script executable on the command-line, it could notify you so you don't clobber over that.
Yeah, lots of possibilities, I wonder at what point it all becomes too annoying :)
I get the reload indicator if ./tempdir/file1 is more recent than ./file1 (and ./file1 is open in Geany).
Isn't that the situation with your reproduce instructions in the OP, `temp/file1` is created after `./file1`? Which is why it worked for me.
No. I didn't think of the time factor before it was mentioned above.
Which means my instructions to reproduce were a bit off. Whenever I had reproduced, it was the open ./file1 that was always more recent because that's the one I was frequently saving while editing.
not sure if it matters now but I'll edit the instructions
How are you telling Geany to open the file? If you want to get on-disk contents just reload.
Doh! was trying with "open"... reload works.
I am not sure why Geany doesn't test equals which would handle both.
I suspect it is, or was, to avoid getting notified by Geany's own changes to the files. This might have been fixed since then, or there might be a better fix.
I suspect it is, or was, to avoid getting notified by Geany's own changes to the files. This might have been fixed since then, or there might be a better fix.
I thought that, but it shouldn't be a problem with local disks since the OS controls mtime.
IIUC there used to be a problem with network file systems since they use the server time for mtime, but if the server hadn't finished writing the file when the application did what Geany does and stats to get the timestamp shortly after a close, the stat gets the clients idea of mtime and the servers was likely later (newer). But would trigger the message on the next stat when the client had updated its time, so it can't be for that. And at least on Linux and NFS thats now fixed by forcing a sync with the server before a stat is returned, so mtimes are the same, don't know about Samba.
Or maybe in its really really early life (I didn't go back in history past ten years but I have a vague memory) the system time was used for the timestamp after save instead of statting the file again, it would always be newer or the same as the disk time so equals wouldn't work.
I have experimentally changed the test to `!=` and so far so good, will see how it goes, but I don't have any network storage systems so its not a really good test.
If we used GFile everywhere, we could make use of its [etag feature](https://developer.gnome.org/gio/stable/GFile.html#gfile-etag) -- and hope it's reliable.
If we used GFile everywhere, we could make use of its etag feature -- and hope it's reliable.
If its reliable why doesn't g_file_monitor use it and so become reliable? And perhaps it is more reliable now, or a better filtering algorithm could be used inside Geany to remove the excess triggers, "somebody" could try since the code is still there, albeit probably bitrotted since it hasn't been enabled..
And the GFiles could come from GVFS so Geany could handle more than just files visible in the local filesystem (without FUSE).
If its reliable why doesn't g_file_monitor use it and so become reliable?
I think you're conflating two separate things. The issue with GFileMonitor is related to inotify, or whatever underlying file change monitoring mechanism, and not the use of GFile.
I think you're conflating two separate things. The issue with GFileMonitor is related to inotify, or whatever underlying file change monitoring mechanism, and not the use of GFile.
Thats correct, but I mean that if they are correct, why don't file monitors then use the etag to solve the issue of if the file really changed and avoid multiple changed signals to the user?
Or thats also possibly the "better filtering" inside Geany.
github-comments@lists.geany.org