hi,
I wasn't sure if this is really happening or I just do something differently... But it is...
**the problem:** I have an open file in Geany... and I have made some changes to it... but haven't saved it typed "//1234" at line 6, for example...
If I open this file in another text editor... and type "//5678"... @ line 6 or anywhere... and save it... the reload dialog shows up...
**GOOD...**
BUT when I download files from the server with Filezilla... and overwrite it... no dialog shows up at all...
whereas in other text editors, Kate, for example, it does: do you want to reload the file?
I'm already using KATE... but I love Geany... I just can't risk uploading an old version of a file overwriting work that has been done....
Peter .................................................. system info: https://termbin.com/5rti
- - - thank you for developing Geany!! - - -
Does Filezilla set the file modified date/time of the file to the remote file date/time each upload?
If so it won't change if the file on disk has not changed since the last upload (the scenario you describe above "... but haven't saved it").
As Geany uses the modified date/time of the file to drive the reload query it won't see any change if the file date/time does not change. But saving from another editor sets the modified date/time and triggers the query.
Nothing in the scenario touches the buffer in Geany, it is not connected to the file on disk, your magnum opus of "//1234" is still there, just save it. In fact I would have thought the risk of losing it was increased if you get multiple reload queries, thats multiple chances to accidentally say "yes".
Kate may use another metric to indicate "changed" or maybe it uses the OS `inotify` facility.
But `inotify` (and therefore its Glib wrapper `g_file_monitor`) has limitations and bugs (described in `man inotify`) and although it was tried in Geany it was disabled because it missed changes, does not see files on remote filesystems, and doubled up reports of changes.
"Does Filezilla set the file modified date/time of the file to the remote file date/time each upload?"
yes, at both uploads and downloads it puts the time in sync
"If so it won't change if the file on disk has not changed since the last upload (the scenario you describe above "... but haven't saved it")."
this sounds logical... "_BUT_"... (**AND** you are right) if I download a file from the server... the file's last mod time changes... .... I wanted to say: _in the critical scenario that time is older than the last known "last mod time"..._ but not! in fact: in the critical scenario **that time is the same time as it was before the edit**
------------------------------ THIS IS LOGICAL (I see now!)
**BUT:::::::**
forget my editing without saving it.... I just edited the file on the server using putty (saved it)
downloaded it... with Filezilla... overwriting the local file...
Geany didn't react... Kate offered the reload...
WHEREAS: When I did the same thing... BUT afterwards "refreshed" the file list in Filezilla... server side... (now showing the right last mod time)
after I downloaded the file, overwriting the local one, Geany offered the reload and Kate did it too...
------------ NOTES: Most of the times I had that file "edited" in Filezilla... which meant that once it changes on the local disk, it will offer to upload...
THEN I turned it off... and restarted Filzeilla without editing the file (marking it as being edited) in Filezilla...
THEN (still) clearly...
When I download a new version from the server... (in Filezilla)
Geany will ONLY react when I reload the server side file list... and see with my eye the real last mod date next to the file Geany in this case will react as expected... Kate will react as expected regardless of the Filezilla server side file list refreshing
----------------------------------------------- bottom line:
the scenario I'm talking about... starts with opening Filezilla afresh... (cause it is anew day, a new working session) and downloading the files from the server (in a given directory) When this happens... Geany will notice the file changes as expected... so the fact that a file is open in geany since the last working session CANNOT cause a sync mistake...
So, we can take this as a "scientific" experiment... without any dissonant results :)
THANK YOU for your help & time!!
Peter
Closed #3839 as completed.
github-comments@lists.geany.org