Hi Jon,
Some general comments first. Note I didn't have anything to do with the current design so this is a post facto analysis with no axe to grind.
Files can go missing in any filesystem but clearly it happens more in networked ones. When that happens an application can't make any assumptions about the state of the system, so it has to ask the user for assistance to regain a consistent view of the state.
Since it doesn't know the status of the directory the file was in or even the whole filesystem, and finding out could cause long delays as things time out, it is reasonable to ask the user where it is safe to save the file.
When a file of the same name re-appears the application can't know if it is intended to be the same object, so it has to ask the user.
On 15 May 2010 03:02, Jon Senior jon@restlesslemon.co.uk wrote:
On Fri, 14 May 2010 18:42:26 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Sigh. So much work just to save files :(.
I don't know if it makes any difference, but I regularly use geany over an sshfs connection with few or no problems. The issues that I have found (and I don't know if the change in back end would have any effect on this) are:
- Saving large files is very slow, even for minor changes. I think that
this is an sshfs thing and probably beyond geany's control.
- If the connection goes down, geany detects that the file is no longer
there and prompts me to resave it.
To reduce the chances of losing work it tries to find a safe place to save the file ASAP, which I think is a good response. You are perfectly at liberty to choose to ignore the risk, ie Geany lets you cancel the save.
If I ignore this and re-open the connection, I have to use reload to force geany to cancel the "dirty file" flag.
Again Geany needs to be able to find out the relationship between its memory buffer and the object of the same name that just re-appeared. The options offered are safe, but not complete, either reload guaranteeing consistency or leave the question open by cancelling. There is no option to re-associate the file system object and the memory buffer without reloading.
Once reloaded, the first save (Ctrl-S) is treated as a Save As... opening the save dialog box.
If the reload dialog had an option to re-associate the memory buffer with the file without reloading, then this would be just a save not a save as.
This would be fine, but if the directory contains a lot of files (~350) the time taken to display the dialog becomes very long (~ 5 minutes). This is far slower than a simple ls, so clearly the dialog is probing other details from the files. All of which means that a broken ssh connection can take upward of 5 mins before work can continue.
The probing etc is most likely to be in the GTK filechooser dialog and outside Geany's control.
The second problem seems to be a problem of internal logic within geany although I can't simulate it by "touching" a file so I think it only happens if a file goes missing.
Yes, AFAICT when the file goes missing and reappears. Touching should only prompt a reload since the contents of the filesystem object associated with the buffer may have unexpectedly changed, the object is still the same (as far as Geany can tell).
@Enrico, if its decided that Geany should make up for the deficiencies in the operating system and libraries it would still need to support older versions of GTK without GIO, making the whole filesystem interface part rather messy with lots of potential maintenance.
Also how do config and project and similar files get on? IIRC they just call g_key_file which doesn't have all this complexity, I guess config is always local in your home directory, but what happens if the project file can't save? Then again I've worked in companies where the home directory was NFSed from a file server.
Cheers Lex
Jon
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel