[Geany-devel] Safe file saving - permissions issue

[Lex Trotman]

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 at restlesslemon.co.uk> wrote:

> On Fri, 14 May 2010 18:42:26 +0200
> Enrico Tröger <enrico.troeger at 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20100515/a5ee4e18/attachment.html>