I've found one more issue with Geany's "Safe file saving" option. When using g_file_set_contents(), file ownership and permissions are replaced with those for a new file. That fully conforms to GLib documentation (http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-file...), but is not good sometimes (e.g. editing an executable script file). I propose to use GIO API (GFile) instead of g_file_set_contents; the patch is attached. This solution, however, raises some questions: - It does work for my system (Ubuntu 9.10), but will it work for others, especially Windows? It seems that GIO is also available on Win32, but it requires some testing - This cannot be named "Safe" file saving, as it does not create a backup first (we can call g_file_replace_contents with make_backup = TRUE, but it would not delete this backup file when the operation completes). Maybe there should be some other configuration option to use (or not to use) this setting? Or should I replace "unsafe" file saving with GIO functions instead of replacing "safe"? Or even more - make this option work like in GEdit (which, I suppose, uses g_file_replace_contents for both cases, with make_backup=TRUE in "safe" case), adding the corresponding checkbox to preferences dialog? What do you think?
On Tue, 30 Mar 2010 16:28:25 +0400, Алексей wrote:
Hi,
I've found one more issue with Geany's "Safe file saving" option. When using g_file_set_contents(), file ownership and permissions are replaced with those for a new file. That fully conforms to GLib documentation (http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-file...), but is not good sometimes (e.g. editing an executable script file). I
this is why I hate that way of saving files and why this option in Geany is hidden and disabled by default.
propose to use GIO API (GFile) instead of g_file_set_contents; the patch is attached. This solution, however, raises some questions:
- It does work for my system (Ubuntu 9.10), but will it work for
others, especially Windows? It seems that GIO is also available on Win32, but it requires some testing
- This cannot be named "Safe" file saving, as it does not create a
backup first (we can call g_file_replace_contents with make_backup = TRUE, but it would not delete this backup file when the operation completes). Maybe there should be some other configuration option to use (or not to use) this setting? Or should I replace "unsafe" file saving with GIO functions instead of replacing "safe"? Or even more - make this option work like in GEdit (which, I suppose, uses g_file_replace_contents for both cases, with make_backup=TRUE in "safe" case), adding the corresponding checkbox to preferences dialog? What do you think?
Using the GIO API would require GLib 2.16. Currently we depend on 2.8. Technically, we surely could do it conditionally but that would make the could less readable, harder to maintain (it's already a mess with the GIO file monitoring which doesn't work as it should :( ) and finally, since to make any more use of this function than the current "unsafe" save method, we need the make_backup flag set to TRUE. In that case, we would need to delete the backup file after a successful save operation. I'm not totally against it but it sounds like quite some overhead to me.
Btw, there is a bug report[1] about the patch you sent a while ago. Maybe you want to have a look when you have time for.
[1] http://sourceforge.net/tracker/index.php?func=detail&aid=2961598&gro...
Regards, Enrico
Hi,
I've considered that bug on sourceforge. According to it,"other editors (e.g. gvim) also have problems saving to a dav:// URL, but they do not blank the file. gedit works just fine here.". GEdit seems to work via GIO, so the only more or less reliable solution is to use GIO where possible.
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch ASAP.
Tue, 30 Mar 2010 23:35:22 +0200 письмо от Enrico Tr?ger enrico.troeger@uvena.de:
On Tue, 30 Mar 2010 16:28:25 +0400, Алексей wrote:
Hi,
I've found one more issue with Geany's "Safe file saving" option. When using g_file_set_contents(), file ownership and permissions are replaced with those for a new file. That fully conforms to GLib documentation (http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-file...), but is not good sometimes (e.g. editing an executable script file). I
this is why I hate that way of saving files and why this option in Geany is hidden and disabled by default.
propose to use GIO API (GFile) instead of g_file_set_contents; the patch is attached. This solution, however, raises some questions:
- It does work for my system (Ubuntu 9.10), but will it work for
others, especially Windows? It seems that GIO is also available on Win32, but it requires some testing
- This cannot be named "Safe" file saving, as it does not create a
backup first (we can call g_file_replace_contents with make_backup = TRUE, but it would not delete this backup file when the operation completes). Maybe there should be some other configuration option to use (or not to use) this setting? Or should I replace "unsafe" file saving with GIO functions instead of replacing "safe"? Or even more - make this option work like in GEdit (which, I suppose, uses g_file_replace_contents for both cases, with make_backup=TRUE in "safe" case), adding the corresponding checkbox to preferences dialog? What do you think?
Using the GIO API would require GLib 2.16. Currently we depend on 2.8. Technically, we surely could do it conditionally but that would make the could less readable, harder to maintain (it's already a mess with the GIO file monitoring which doesn't work as it should :( ) and finally, since to make any more use of this function than the current "unsafe" save method, we need the make_backup flag set to TRUE. In that case, we would need to delete the backup file after a successful save operation. I'm not totally against it but it sounds like quite some overhead to me.
Btw, there is a bug report[1] about the patch you sent a while ago. Maybe you want to have a look when you have time for.
[1] http://sourceforge.net/tracker/index.php?func=detail&aid=2961598&gro...
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
ATTACHMENT: application/pgp-signature _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Новые Карты@Mail.Ru с пробками и спутниками! http://r.mail.ru/cln4831/map.mail.ru/
On Wed, 31 Mar 2010 14:41:20 +0400 Алексей Антипов 1a_antipov@mail.ru wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new file. Does g_file_replace_contents() handle this problem? (g_file_set_contents () does handle this but as you mention has other problems).
So while it's great you found a solution to the gvfs bugs, ideally we would have one function that works everywhere. It seems possible but may be a pain trying to get it to work :-/
Just wanted to mention this.
Regards, Nick
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new file. Does g_file_replace_contents() handle this problem? (g_file_set_contents () does handle this but as you mention has other problems).
According to the docs for g_file_replace, which g_file_replace_contents uses internally, this case may be handled:
"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed." http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
Hopefully it still keeps permissions if the rename is done(!)
Regards, Nick
Sure, it does not alter permissions.
I suppose that with make_backup=TRUE it would first (attempt to) copy previous file to a backup file, and only then write a new one. The annoying thing is that it would not delete a backup file, and the only way to get its name is to "guess" (usually for "filename" the backup name is "filename~"). Probably the backup file can be left as it is, so a user gets a copy of his/her old data; those who are annoyed with that can simply turn the option off.
I've created a patch which requires some final testing; I'll send it today or tomorrow (can test only with smb:// and sftp://, 'cause have nothing else:))
Thu, 1 Apr 2010 17:07:59 +0100 письмо от Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new file. Does g_file_replace_contents() handle this problem? (g_file_set_contents () does handle this but as you mention has other problems).
According to the docs for g_file_replace, which g_file_replace_contents uses internally, this case may be handled:
"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed." http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
Hopefully it still keeps permissions if the rename is done(!)
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Тесты новейших гаджетов на Hi-tech.Mail.Ru http://r.mail.ru/cln5823/hi-tech.mail.ru/
Please find the patch in attachment. When building with GIO, it would use g_file_replace_contents Also, for those who are interested, I have found the reason for strange behaviour with gvfs-smb. The proposed patch is here: https://bugzilla.gnome.org/show_bug.cgi?id=614696
Fri, 02 Apr 2010 12:12:36 +0400 письмо от Алексей Антипов1a_antipov@mail.ru:
Sure, it does not alter permissions.
I suppose that with make_backup=TRUE it would first (attempt to) copy previous file to a backup file, and only then write a new one. The annoying thing is that it would not delete a backup file, and the only way to get its name is to "guess" (usually for "filename" the backup name is "filename~"). Probably the backup file can be left as it is, so a user gets a copy of his/her old data; those who are annoyed with that can simply turn the option off.
I've created a patch which requires some final testing; I'll send it today or tomorrow (can test only with smb:// and sftp://, 'cause have nothing else:))
Thu, 1 Apr 2010 17:07:59 +0100 письмо от Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new file. Does g_file_replace_contents() handle this problem? (g_file_set_contents () does handle this but as you mention has other problems).
According to the docs for g_file_replace, which g_file_replace_contents uses internally, this case may be handled:
"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed." http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
Hopefully it still keeps permissions if the rename is done(!)
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Тесты новейших гаджетов на Hi-tech.Mail.Ru http://r.mail.ru/cln5823/hi-tech.mail.ru/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Лучшие предложения интернет-магазинов на Товары@Mail.Ru http://r.mail.ru/cln4267/torg.mail.ru/
On Sat, 03 Apr 2010 03:51:18 +0400 Алексей Антипов 1a_antipov@mail.ru wrote:
Please find the patch in attachment. When building with GIO, it would use g_file_replace_contents
I think this is a good idea (but haven't tested it as I don't have GIO). However, I don't think we should change the meaning of the 'safe file saving' pref. What if there's a bug in GIO? At least we know that pref doesn't lose data.
We could maybe add a 'backup' Geany pref for GIO as this is probably more efficient than the Save Actions plugin backup option.
P.S. Please don't top-post ;-)
Fri, 02 Apr 2010 12:12:36 +0400 письмо от Алексей Антипов1a_antipov@mail.ru:
Sure, it does not alter permissions.
I suppose that with make_backup=TRUE it would first (attempt to) copy previous file to a backup file, and only then write a new one. The annoying thing is that it would not delete a backup file, and the only way to get its name is to "guess" (usually for "filename" the backup name is "filename~"). Probably the backup file can be left as it is, so a user gets a copy of his/her old data; those who are annoyed with that can simply turn the option off.
I've created a patch which requires some final testing; I'll send it today or tomorrow (can test only with smb:// and sftp://, 'cause have nothing else:))
Thu, 1 Apr 2010 17:07:59 +0100 письмо от Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch ASAP.
Regards, Nick
On Tue, 6 Apr 2010 12:10:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 03 Apr 2010 03:51:18 +0400 Алексей Антипов 1a_antipov@mail.ru wrote:
Please find the patch in attachment. When building with GIO, it would use g_file_replace_contents
I think this is a good idea (but haven't tested it as I don't have GIO). However, I don't think we should change the meaning of the 'safe file saving' pref. What if there's a bug in GIO? At least we know that pref doesn't lose data.
I've still been using a GLib 2.14 system (so haven't personally tested this), but I think we ought to try using GIO for document saving as it may fix the network file truncation problems.
I attach an edited version of Алексей's patch, which doesn't make backups. Please test - if GIO saving is used then you should see a debug message "Using GIO to save: /path/foo.c" on saving. File permissions hopefully will be maintained.
I suggest we apply it (but maybe with a new hidden pref use_old_file_saving if we include it in a release, in case it doesn't work for some people).
Алексей: I know it's a long time later, but 2 questions: 1. Where is HAVE_GIO defined? Should we use a version check for GLib 2.16 instead? 2. I'm assuming there's no need to free the GFile from g_file_new_for_path?
Also just to mention: we don't use C++ style comments and don't allow variable declarations after code (g_return_val_if_fail) for portability - that's also my purpose in editing the patch.
Regards, Nick
Hello, Nick!
Here are the answers to your 2 questions:
- Where is HAVE_GIO defined? Should we use a version check for GLib
2.16 instead?
configure.ac:141
# GIO checks gio_modules="gio-2.0 >= 2.16" PKG_CHECK_MODULES(GIO, [$gio_modules], have_gio=1, have_gio=0) AC_SUBST(GIO_CFLAGS) AC_SUBST(GIO_LIBS) if test $have_gio = 1 ; then AC_DEFINE(HAVE_GIO, 1, [Whether GIO is available]) fi
Don't know if GLib can be compiled without GIO, but it seems there were reasons for checking gio-2.0, not glib-2.0
- I'm assuming there's no need to free the GFile from
g_file_new_for_path?
I haven't found any notice at http://library.gnome.org/devel/gio/stable/GFile.html, so I assume there's no need to do this.
It's been very long since I made this patch, so I don't remember all the details. Please feel free to modify and include it as you want, but let me know if (and when) it has been commited.
Regards, Alexey
On 09/10/2010 09:35 AM, Nick Treleaven wrote:
On Tue, 6 Apr 2010 12:10:13 +0100 Nick Treleavennick.treleaven@btinternet.com wrote:
On Sat, 03 Apr 2010 03:51:18 +0400 Алексей Антипов1a_antipov@mail.ru wrote:
Please find the patch in attachment. When building with GIO, it would use g_file_replace_contents
I think this is a good idea (but haven't tested it as I don't have GIO). However, I don't think we should change the meaning of the 'safe file saving' pref. What if there's a bug in GIO? At least we know that pref doesn't lose data.
I've still been using a GLib 2.14 system (so haven't personally tested this), but I think we ought to try using GIO for document saving as it may fix the network file truncation problems.
I attach an edited version of Алексей's patch, which doesn't make backups. Please test - if GIO saving is used then you should see a debug message "Using GIO to save: /path/foo.c" on saving. File permissions hopefully will be maintained.
I patched and compiled and opened and saved a few files on the remote FTP severs that had been giving me trouble with fwrite, and it seemed to work fine, very slow but it worked, but no debug message...should I be changing something in the config possibly? Or maybe I didn't patch it correctly and this is a false positive?
Regards,
Brad
On 30 September 2010 11:36, Brad Wilson brad@rhift.com wrote:
On 09/10/2010 09:35 AM, Nick Treleaven wrote:
On Tue, 6 Apr 2010 12:10:13 +0100 Nick Treleavennick.treleaven@btinternet.com wrote:
On Sat, 03 Apr 2010 03:51:18 +0400 Алексей Антипов1a_antipov@mail.ru wrote:
Please find the patch in attachment. When building with GIO, it would use g_file_replace_contents
I think this is a good idea (but haven't tested it as I don't have GIO). However, I don't think we should change the meaning of the 'safe file saving' pref. What if there's a bug in GIO? At least we know that pref doesn't lose data.
I've still been using a GLib 2.14 system (so haven't personally tested this), but I think we ought to try using GIO for document saving as it may fix the network file truncation problems.
I attach an edited version of Алексей's patch, which doesn't make backups. Please test - if GIO saving is used then you should see a debug message "Using GIO to save: /path/foo.c" on saving. File permissions hopefully will be maintained.
I patched and compiled and opened and saved a few files on the remote FTP severs that had been giving me trouble with fwrite, and it seemed to work fine, very slow but it worked, but no debug message...should I be changing something in the config possibly? Or maybe I didn't patch it correctly and this is a false positive?
Did you run with --verbose?
Cheers Lex
Regards,
Brad
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 09/29/2010 09:37 PM, Lex Trotman wrote:
On 30 September 2010 11:36, Brad Wilsonbrad@rhift.com wrote:
On 09/10/2010 09:35 AM, Nick Treleaven wrote:
On Tue, 6 Apr 2010 12:10:13 +0100 Nick Treleavennick.treleaven@btinternet.com wrote:
On Sat, 03 Apr 2010 03:51:18 +0400 Алексей Антипов1a_antipov@mail.ru wrote:
Please find the patch in attachment. When building with GIO, it would use g_file_replace_contents
I think this is a good idea (but haven't tested it as I don't have GIO). However, I don't think we should change the meaning of the 'safe file saving' pref. What if there's a bug in GIO? At least we know that pref doesn't lose data.
I've still been using a GLib 2.14 system (so haven't personally tested this), but I think we ought to try using GIO for document saving as it may fix the network file truncation problems.
I attach an edited version of Алексей's patch, which doesn't make backups. Please test - if GIO saving is used then you should see a debug message "Using GIO to save: /path/foo.c" on saving. File permissions hopefully will be maintained.
I patched and compiled and opened and saved a few files on the remote FTP severs that had been giving me trouble with fwrite, and it seemed to work fine, very slow but it worked, but no debug message...should I be changing something in the config possibly? Or maybe I didn't patch it correctly and this is a false positive?
Did you run with --verbose?
=) That did it. Thanks,
Brad
On Fri, 10 Sep 2010 15:35:59 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I've still been using a GLib 2.14 system (so haven't personally tested this), but I think we ought to try using GIO for document saving as it may fix the network file truncation problems.
I attach an edited version of Алексей's patch, which doesn't make backups. Please test - if GIO saving is used then you should see a debug message "Using GIO to save: /path/foo.c" on saving. File permissions hopefully will be maintained.
I suggest we apply it (but maybe with a new hidden pref use_old_file_saving if we include it in a release, in case it doesn't work for some people).
I've now committed this patch to SVN for further testing. Thanks again to Алексей.
Nick
On 2 April 2010 03:07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably
before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch
ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new file. Does g_file_replace_contents() handle this problem? (g_file_set_contents () does handle this but as you mention has other problems).
According to the docs for g_file_replace, which g_file_replace_contents uses internally, this case may be handled:
"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed." http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
Hopefully it still keeps permissions if the rename is done(!)
I would doubt it :-( its creating the new temporary file then renaming that to the original name. This leaves it with the permissions of the temporary file ie those of a new file. It might work if it copies the attributes of the old file to the temporary first, but thats a backend dependent action since permissions depend on the filesystem.. But it does leave the old file unharmed on out of space :-)
The problem is that remote file systems (most anyway) do not actually have an atomic rename and delete operation. In fact many actually have race conditions when you try to remove the old file and then rename the temporary as a non-atomic pair of operations. So just because it seems to work for one application doesn't mean it will allways work for it with a different remote file system. Something like that can be the cause of an empty file.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
As goes from GLib sources, the final replace strategy is backend-dependent. For local files: (from GLib sources, gio/glocalfileoutputstream.c, handle_overwrite_open): /* We use two backup strategies. * The first one (which is faster) consist in saving to a * tmp file then rename the original file to the backup and the * tmp file to the original name. This is fast but doesn't work * when the file is a link (hard or symbolic) or when we can't * write to the current dir or can't set the permissions on the * new file. * The second strategy consist simply in copying the old file * to a backup file and rewrite the contents of the file. */ For smb:// files (from GVFS sources, daemon/gvfsbackendsmb.c, do_replace) /* Backup strategy: * * By default we: * 1) save to a tmp file (that doesn't exist already) * 2) rename orig file to backup file * (or delete it if no backup) * 3) rename tmp file to orig file * * However, this can fail if we can't write to the directory. * In that case we just truncate the file, after having * copied directly to the backup filename. */ SFTP backend strategy is much more complex So, let's sum it all up
1. There are (at least) 3 different ways to save a file: - Use POSIX fopen()/fwrite() API - Use g_file_set_contents() - Use GIO API
2. On remote filesystems at least first (and probably second) API relies on GIO (via virtual filesystem calls or direct GIO calls in newer GLib versions)
3. No API guarantees that data on remote filesystem won't be lost and the save would be "atomic", as the implementation is in the backend, which can be buggy etc.
4. The strategy used by GIO on local filesystem seems satisfactory for "safe file saving" needs.
5. All we can do is minimize the probability of data loss due to our code issues. We cannot directly affect troubles in GLib and GVFS (IMHO they are messy, but one should contact these projects' teams to improve that)
6. The less (buggy) code there is between Geany and final data transfers (either to disk, or via HTTP/FTP/SMB/SSH/whatever-else), the more reliable our project is
7. That's why the use of direct GIO calls instead of fopen() or g_file_set_contents() is attractive. Consider the chains: (1) fopen()/fwrite() -> VFS call -> GIO g_file_do_something() -> Backend -> Final data transfer OR (2a) g_file_set_contents -> fopen()/fwrite() -> VFS call -> GIO g_file_do_something() -> Backend -> Final data transfer OR (2b) g_file_set_contents -> GIO g_file_do_something() -> Backend -> Final data transfer OR (3) GIO g_file_do_something() -> Backend -> Final data transfer
8. The only alternative for g_file_replace here is to write our own backup algorithm implementation, preferably based on direct GIO calls.
Fri, 2 Apr 2010 21:35:49 +1100 письмо от Lex Trotman elextr@gmail.com:
On 2 April 2010 03:07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably
before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch
ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new file. Does g_file_replace_contents() handle this problem? (g_file_set_contents () does handle this but as you mention has other problems).
According to the docs for g_file_replace, which g_file_replace_contents uses internally, this case may be handled:
"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed." http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
Hopefully it still keeps permissions if the rename is done(!)
I would doubt it :-( its creating the new temporary file then renaming that to the original name. This leaves it with the permissions of the temporary file ie those of a new file. It might work if it copies the attributes of the old file to the temporary first, but thats a backend dependent action since permissions depend on the filesystem.. But it does leave the old file unharmed on out of space :-)
The problem is that remote file systems (most anyway) do not actually have an atomic rename and delete operation. In fact many actually have race conditions when you try to remove the old file and then rename the temporary as a non-atomic pair of operations. So just because it seems to work for one application doesn't mean it will allways work for it with a different remote file system. Something like that can be the cause of an empty file.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
"Барахолка" на Товары@Mail.Ru. Покупай дешево, продавай выгодно. http://r.mail.ru/cln4270/torg.mail.ru/used/
2010/4/2 Алексей Антипов 1a_antipov@mail.ru
As goes from GLib sources, the final replace strategy is backend-dependent. For local files: (from GLib sources, gio/glocalfileoutputstream.c, handle_overwrite_open): /* We use two backup strategies.
- The first one (which is faster) consist in saving to a
- tmp file then rename the original file to the backup and the
- tmp file to the original name. This is fast but doesn't work
- when the file is a link (hard or symbolic) or when we can't
I don't understand why it fails with a hard link, all files *are* hard links so that means it would never work, do you understand what they mean?
- write to the current dir or can't set the permissions on the
- new file.
- The second strategy consist simply in copying the old file
- to a backup file and rewrite the contents of the file.
*/
Yup, thats as I understand the process
For smb:// files (from GVFS sources, daemon/gvfsbackendsmb.c, do_replace) /* Backup strategy: * * By default we: * 1) save to a tmp file (that doesn't exist already) * 2) rename orig file to backup file * (or delete it if no backup) * 3) rename tmp file to orig file * * However, this can fail if we can't write to the directory. * In that case we just truncate the file, after having * copied directly to the backup filename. */
I don't like the bit about truncating the file, how did it copy the backup if it can't write?
SFTP backend strategy is much more complex So, let's sum it all up
- There are (at least) 3 different ways to save a file:
- Use POSIX fopen()/fwrite() API
- Use g_file_set_contents()
- Use GIO API
- On remote filesystems at least first (and probably second) API relies on
GIO (via virtual filesystem calls or direct GIO calls in newer GLib versions)
- No API guarantees that data on remote filesystem won't be lost and the
save would be "atomic", as the implementation is in the backend, which can be buggy etc.
Yes, so Geany should be careful but not paranoid, some things it just can't control.
- The strategy used by GIO on local filesystem seems satisfactory for
"safe file saving" needs.
Yes, its probably the best.
- All we can do is minimize the probability of data loss due to our code
issues. We cannot directly affect troubles in GLib and GVFS (IMHO they are messy, but one should contact these projects' teams to improve that)
Agree
- The less (buggy) code there is between Geany and final data transfers
(either to disk, or via HTTP/FTP/SMB/SSH/whatever-else), the more reliable our project is
Agree
- That's why the use of direct GIO calls instead of fopen() or
g_file_set_contents() is attractive. Consider the chains: (1) fopen()/fwrite() -> VFS call -> GIO g_file_do_something() -> Backend -> Final data transfer
I don't understand why the C library calls fopen and fwrite call GIO, for file systems supported natively on the platform they should directly perform actions on that file system, for others they would have to go via fuse and the path you have shown, unless GVFS is taking over the whole file system and forcing all file system operations via itself :-( very bad if so. Impacts performance, reliability and maintainability.
OR (2a) g_file_set_contents -> fopen()/fwrite() -> VFS call -> GIO g_file_do_something() -> Backend -> Final data transfer OR
As per note above.
(2b) g_file_set_contents -> GIO g_file_do_something() -> Backend -> Final data transfer OR (3) GIO g_file_do_something() -> Backend -> Final data transfer
- The only alternative for g_file_replace here is to write our own backup
algorithm implementation, preferably based on direct GIO calls.
As I said above Geany needs to be careful, not paranoid, so I don't think adding another layer is sensible. Geany also needs to be portable so it needs to handle GIO when available and non-GIO when not and windows with similar levels of competence. If there are problems in the backends I would not expect Geany to compensate for them.
Cheers Lex
Fri, 2 Apr 2010 21:35:49 +1100 письмо от Lex Trotman elextr@gmail.com:
On 2 April 2010 03:07, Nick Treleaven nick.treleaven@btinternet.com
wrote:
On Thu, 1 Apr 2010 12:41:13 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably
before), so I think we can safely use fopen() and fprintf()/fwrite()
there.
Then, your proposal about version separation (use GIO with GLib>=2.16
and
fopen()/g_file_set_contents() with other) is extremely attractive. Do
you
know if there is a way to get GLib version at runtime, not at
compile-time
(so that there is no need to rebuild all the packages for different versions)?
I'm going to start working on it; if this is OK, I'll send a patch
ASAP.
BTW There is another problem that file saving should solve - not losing existing file data when there is no space to save the new
file.
Does g_file_replace_contents() handle this problem?
(g_file_set_contents
() does handle this but as you mention has other problems).
According to the docs for g_file_replace, which g_file_replace_contents uses internally, this case may be handled:
"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed." http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
Hopefully it still keeps permissions if the rename is done(!)
I would doubt it :-( its creating the new temporary file then renaming
that
to the original name. This leaves it with the permissions of the
temporary
file ie those of a new file. It might work if it copies the attributes of the old file to the
temporary
first, but thats a backend dependent action since permissions depend on
the
filesystem.. But it does leave the old file unharmed on out of space :-)
The problem is that remote file systems (most anyway) do not actually
have
an atomic rename and delete operation. In fact many actually have race conditions when you try to remove the old file and then rename the
temporary
as a non-atomic pair of operations. So just because it seems to work for one application doesn't mean it will allways work for it with a different remote file system. Something like that can be the cause of an empty
file.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
"Барахолка" на Товары@Mail.Ru. Покупай дешево, продавай выгодно. http://r.mail.ru/cln4270/torg.mail.ru/used/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi,
Lex Trotman a écrit :
2010/4/2 Алексей Антипов <1a_antipov@mail.ru mailto:1a_antipov@mail.ru>
As goes from GLib sources, the final replace strategy is backend-dependent. For local files: (from GLib sources, gio/glocalfileoutputstream.c, handle_overwrite_open): /* We use two backup strategies. * The first one (which is faster) consist in saving to a * tmp file then rename the original file to the backup and the * tmp file to the original name. This is fast but doesn't work * when the file is a link (hard or symbolic) or when we can'tI don't understand why it fails with a hard link, all files *are* hard links so that means it would never work, do you understand what they mean?
I think they mean it would break the links, which is actually true: hard links points to the file's data, then a simple rename() does NOT break the link, and then the hard links would not point to the newly created file. Of course, it is not a problem if the file have only one link (simple file) since there is only one entry point.
I don't understand why the C library calls fopen and fwrite call GIO, for file systems supported natively on the platform they should directly perform actions on that file system, for others they would have to go via fuse and the path you have shown, unless GVFS is taking over the whole file system and forcing all file system operations via itself :-( very bad if so. Impacts performance, reliability and maintainability.
I think too that GVFS have nothing to do here, only a "real" or FUSE FS, nothing more. But I might be wrong.
Geany also needs to be portable so it needs to handle GIO when available and non-GIO when not and windows with similar levels of competence.
Yes, but I think it should not prevent a specific improvement if it worth it (e.g. if it fixes a real problem that can't be fixed reliably with more generic code). I mean "similar" should be taken only as "don't let one be bad", not "don't let one be amazing".
If there are problems in the backends I would not expect Geany to compensate for them.
Of course not (I think).
I think the best way is to use GIO when possible, since it is meant for that; and it is unrealistic to handle each and every limitation of filesystems from inside a program (like geany or whatever). What if an unknown remote FS doesn't support feature X or Y (or not the way they may be expected to) we rely on? The only viable solution is a specific handling of this kind of cases. What a better place than an IO abstraction layer? But of course then, the point is the trust (and actual correctness) in the IO layer. Even if GIO have probably many bugs (as each and every program or library), I think it could be trusted: 1) it is an IO layer, then it is its role; 2) it is an active project that (should) fix the defects when found; 3) well... as said above, could we better trust our own code? I mean, GIO is not a funky joke made by drunk peoples, and it is not only used by two monkeys on a starship: bugs will be found and fixed.
Of course this doesn't apply if the IO layer doesn't support the needed feature (actually, safe file saving with correct permissions).
That's my two pounds... but consider I didn't go deep in the subject and it may be a somewhat wrong consideration, don't take this as if said after months of tests, thoughts and audit.
Regards, Colomban
On 3 April 2010 13:20, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Lex Trotman a écrit :
2010/4/2 Алексей Антипов <1a_antipov@mail.ru <mailto:1a_antipov@mail.ru
As goes from GLib sources, the final replace strategy is backend-dependent. For local files: (from GLib sources, gio/glocalfileoutputstream.c, handle_overwrite_open): /* We use two backup strategies. * The first one (which is faster) consist in saving to a * tmp file then rename the original file to the backup and the * tmp file to the original name. This is fast but doesn't work * when the file is a link (hard or symbolic) or when we can'tI don't understand why it fails with a hard link, all files *are* hard links so that means it would never work, do you understand what they
mean? I think they mean it would break the links, which is actually true: hard links points to the file's data, then a simple rename() does NOT break the link, and then the hard links would not point to the newly created file. Of course, it is not a problem if the file have only one link (simple file) since there is only one entry point.
Yes, its badly worded :-) what is meant is that if a file has more than one hard link, all the other links continue to point to the original data. For mine this is correct and expected behaviour so "won't work" comment threw me.
I don't understand why the C library calls fopen and fwrite call GIO, for file systems supported natively on the platform they should directly perform actions on that file system, for others they would have to go via fuse and the path you have shown, unless GVFS is taking over the whole file system and forcing all file system operations via itself :-( very bad if so. Impacts performance, reliability and maintainability.
I think too that GVFS have nothing to do here, only a "real" or FUSE FS, nothing more. But I might be wrong.
I'd say we are right, gio local file handling uses fopen and fwrite, it would be an infinite loop if they were re-directed.
Geany also needs to be portable so it needs to handle GIO when available and non-GIO when not and windows with similar levels of competence.
Yes, but I think it should not prevent a specific improvement if it worth it (e.g. if it fixes a real problem that can't be fixed reliably with more generic code). I mean "similar" should be taken only as "don't let one be bad", not "don't let one be amazing".
Agree, I should have said to the same minimum level of competence.
If there are problems in the backends I would not expect Geany to compensate for them.
Of course not (I think).
I think the best way is to use GIO when possible, since it is meant for that; and it is unrealistic to handle each and every limitation of filesystems from inside a program (like geany or whatever). What if an unknown remote FS doesn't support feature X or Y (or not the way they may be expected to) we rely on? The only viable solution is a specific handling of this kind of cases. What a better place than an IO abstraction layer? But of course then, the point is the trust (and actual correctness) in the IO layer. Even if GIO have probably many bugs (as each and every program or library), I think it could be trusted:
- it is an IO layer, then it is its role;
- it is an active project that (should) fix the defects when found;
- well... as said above, could we better trust our own code? I mean,
GIO is not a funky joke made by drunk peoples, and it is not only used by two monkeys on a starship: bugs will be found and fixed.
oh, have you seen the code then, millions of extraterrestrial space monkeys and typewriters come to mind :-)
seriously though you are correct.
Of course this doesn't apply if the IO layer doesn't support the needed feature (actually, safe file saving with correct permissions).
At least for local filesystems g_file_replace will try to copy permissions to the temporary file and if that does not work will fall back to copying the content to the backup file, truncating the original file and writing to that, so in most cases it should end up with the initial permissions. But if the write then fails how do you find and restore the backup???
g_file_replace therefore solves the initial problem with using g_file_save_contents for safe file saving :-) and is what Alexey's patch does, thanks
Cheers Lex
That's my two pounds... but consider I didn't go deep in the subject and it may be a somewhat wrong consideration, don't take this as if said after months of tests, thoughts and audit.
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 03 Apr 2010 04:20:14 +0200, Colomban wrote:
Hi all,
sorry for the long delay, I couldn't make myself into this topic again.
I think the best way is to use GIO when possible, since it is meant for that; and it is unrealistic to handle each and every limitation of
I'm unsure what we should do. It's sort of depressing reading about all the problems and different solutions. Long time ago, a simple fwrite() was enough to get data written to the disk. Then, GIO+GVfs arrived and problems began.
Without replying to each detail in the discussion, I see two ways:
- we get the GVfs people to fix their bugs and make the gvfs-fuse backend work correctly
- we switch completely to GIO and depend on GLib 2.16/GTK 2.14 and rewrite any file IO in Geany to do it like GTK wants us to do it
Sigh. So much work just to save files :(.
Regards, Enrico
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. If I ignore this and re-open the connection, I have to use reload to force geany to cancel the "dirty file" flag. Once reloaded, the first save (Ctrl-S) is treated as a Save As... opening the save dialog box. 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 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.
Jon
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
On Sat, 15 May 2010 14:10:06 +1000 Lex Trotman elextr@gmail.com wrote:
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.
I agree. It is more than reasonable, it is to be praised. Better to harass the user a little than to risk losing data.
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.
Even after a reload. Here's the sequence of events (and this doesn't require a network drive to simulate)
touch foo.bar geany foo.bar (assumes an existing session)
[Edit file in geany and save using ctrl-s]
mv foo.bar bar.foo
[Return to geany, you will be prompted that the file can no longer be found and offered a chance to save it. Choose cancel leaving the file open but marked as dirty]
mv bar.foo foo.bar
[Return to geany and choose Reload. You will be asked to confirm and then the file is reloaded and it is no longer marked as dirty. Make a change and save with ctrl-s. You will now be presented with a "Save file" dialog]
This is, I feel, broken logic. The file was marked as dirty but has been reloaded from disk. A file reloaded from disk should be no different from a file freshly loaded for the first time. This does not occur if the file is not moved temporarily. By choosing to reload, the user has already resynchronised the geany buffer with the file and thus re-established the link between the buffer and the file. This final prompt is (in my opinion) superfluous.
Were it not for the painfully long opening time of the save dialog when dealing with a large networked directory of files, it would be a minor inconvenience, but while waiting for the dialog to open, you have time on your hands to think about this stuff! :-)
I don't wish to be critical. This is, frankly, my only issue with geany (I'd love it if it could convert R to optimised C, but I don't think that fits into the description of a lightweight editor!). I know that I'll not have the time to track this down in the source for a while, so I'm putting it out there. I'm happy to submit a proper bug report if requested.
Jon
On 15 May 2010 14:40, Jon Senior jon@restlesslemon.co.uk wrote:
On Sat, 15 May 2010 14:10:06 +1000 Lex Trotman elextr@gmail.com wrote:
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.
I agree. It is more than reasonable, it is to be praised. Better to harass the user a little than to risk losing data.
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.
Even after a reload. Here's the sequence of events (and this doesn't require a network drive to simulate)
touch foo.bar geany foo.bar (assumes an existing session)
[Edit file in geany and save using ctrl-s]
mv foo.bar bar.foo
[Return to geany, you will be prompted that the file can no longer be found and offered a chance to save it. Choose cancel leaving the file open but marked as dirty]
mv bar.foo foo.bar
[Return to geany and choose Reload. You will be asked to confirm and then the file is reloaded and it is no longer marked as dirty. Make a change and save with ctrl-s. You will now be presented with a "Save file" dialog]
I misunderstood, I thought you had said reloading stopped it showing a save dialog. I agree its superfluous if you have reloaded, and as I said I think you should be able to tell Geany that its superfluous even if you didn't reload.
This is, I feel, broken logic. The file was marked as dirty but has been reloaded from disk. A file reloaded from disk should be no different from a file freshly loaded for the first time. This does not occur if the file is not moved temporarily. By choosing to reload, the user has already resynchronised the geany buffer with the file and thus re-established the link between the buffer and the file. This final prompt is (in my opinion) superfluous.
Were it not for the painfully long opening time of the save dialog when dealing with a large networked directory of files, it would be a minor inconvenience, but while waiting for the dialog to open, you have time on your hands to think about this stuff! :-)
Heh heh, can't have users thinking now can we...
I don't wish to be critical. This is, frankly, my only issue with geany (I'd love it if it could convert R to optimised C, but I don't think that fits into the description of a lightweight editor!)
Sounds more like the job description of a compiler :-) but Geany can run one of those for you if you can find one :-)
. I know that I'll not have the time to track this down in the source for a while, so I'm putting it out there. I'm happy to submit a proper bug report if requested.
I'll have a look at the logic and how easy it is to change if no one beats me to it in the next few days.
Cheers Lex
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 15 May 2010 17:34, Lex Trotman elextr@gmail.com wrote:
On 15 May 2010 14:40, Jon Senior jon@restlesslemon.co.uk wrote:
On Sat, 15 May 2010 14:10:06 +1000 Lex Trotman elextr@gmail.com wrote:
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.
I agree. It is more than reasonable, it is to be praised. Better to harass the user a little than to risk losing data.
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.
Even after a reload. Here's the sequence of events (and this doesn't require a network drive to simulate)
touch foo.bar geany foo.bar (assumes an existing session)
[Edit file in geany and save using ctrl-s]
mv foo.bar bar.foo
[Return to geany, you will be prompted that the file can no longer be found and offered a chance to save it. Choose cancel leaving the file open but marked as dirty]
mv bar.foo foo.bar
[Return to geany and choose Reload. You will be asked to confirm and then the file is reloaded and it is no longer marked as dirty. Make a change and save with ctrl-s. You will now be presented with a "Save file" dialog]
I misunderstood, I thought you had said reloading stopped it showing a save dialog. I agree its superfluous if you have reloaded, and as I said I think you should be able to tell Geany that its superfluous even if you didn't reload.
This is, I feel, broken logic. The file was marked as dirty but has been reloaded from disk. A file reloaded from disk should be no different from a file freshly loaded for the first time. This does not occur if the file is not moved temporarily. By choosing to reload, the user has already resynchronised the geany buffer with the file and thus re-established the link between the buffer and the file. This final prompt is (in my opinion) superfluous.
Were it not for the painfully long opening time of the save dialog when dealing with a large networked directory of files, it would be a minor inconvenience, but while waiting for the dialog to open, you have time on your hands to think about this stuff! :-)
Heh heh, can't have users thinking now can we...
I don't wish to be critical. This is, frankly, my only issue with geany (I'd love it if it could convert R to optimised C, but I don't think that fits into the description of a lightweight editor!)
Sounds more like the job description of a compiler :-) but Geany can run one of those for you if you can find one :-)
. I know that I'll not have the time to track this down in the source for a while, so I'm putting it out there. I'm happy to submit a proper bug report if requested.
I'll have a look at the logic and how easy it is to change if no one beats me to it in the next few days.
Cheers Lex
This seems to be because when a document disappears the real path is cleared but when it is reloaded the real path is not set again. I'm not sure about side effects so I am asking Enrico or Nick, in document_open_file_full can the setptr( doc->real_path be moved outside the if (! reload ) safely?
Cheers Lex
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel