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