On Fri, Jan 27, 2012 at 2:42 AM, Nick Treleaven git-noreply@geany.org wrote:
Branch: refs/heads/master Author: Nick Treleaven nick.treleaven@btinternet.com Committer: Nick Treleaven nick.treleaven@btinternet.com Date: Thu, 26 Jan 2012 15:42:06 Commit: 7cc443e1420b77d041815a464fe5b20bc62412f4 https://github.com/geany/geany/commit/7cc443e1420b77d041815a464fe5b20bc62412...
Log Message:
Don't append file truncation warning if file doesn't exist
This warning shown after a failed save is unnecessary when the filename is invalid.
Modified Paths:
src/document.c
Modified: src/document.c 3 files changed, 2 insertions(+), 1 deletions(-) =================================================================== @@ -1766,7 +1766,8 @@ gboolean document_save_file(GeanyDocument *doc, gboolean force) { ui_set_statusbar(TRUE, _("Error saving file (%s)."), errmsg);
- if (!file_prefs.use_safe_file_saving)
- if (!file_prefs.use_safe_file_saving &&
- g_file_test(locale_filename, G_FILE_TEST_IS_REGULAR))
Hi Nick,
If writing a remote file failed half way because of a network failure, then if the network is still faulty when we g_file_test for a regular file, it will fail because the file doesn't exist, but the partly written file may (is likely to) be truncated.
Cheers Lex
{ SETPTR(errmsg, g_strdup_printf(_("%s\n\nThe file on disk may now be truncated!"), errmsg));
This E-Mail was brought to you by github_commit_mail.py (Source: TBD). _______________________________________________ Geany-commits mailing list Geany-commits@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-commits
On 26/01/2012 22:32, Lex Trotman wrote:
If writing a remote file failed half way because of a network failure, then if the network is still faulty when we g_file_test for a regular file, it will fail because the file doesn't exist, but the partly written file may (is likely to) be truncated.
Well, they'll still get a save failed warning with the specific OS error message. Just to check, GFile writes directly to a network file?
Anyway, I don't know how to improve the situation. My commit is necessary to avoid confusing users about truncation on a local file that doesn't even exist.
Nick
On Sat, Jan 28, 2012 at 12:38 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 26/01/2012 22:32, Lex Trotman wrote:
If writing a remote file failed half way because of a network failure, then if the network is still faulty when we g_file_test for a regular file, it will fail because the file doesn't exist, but the partly written file may (is likely to) be truncated.
Well, they'll still get a save failed warning with the specific OS error message. Just to check, GFile writes directly to a network file?
If the file doesn't exist the it could be said that it was the ultimate in truncation :)
Anyway, I don't know how to improve the situation. My commit is necessary to avoid confusing users about truncation on a local file that doesn't even
No, neither do I, but we do get complaints about truncated files on network shares/gvfs every so often, thats why we added the message.
So this change actually prevents the message in its main use-case, where harm may have been done, in favour of a use-case where no harm has been done, and that is bad.
Cheers Lex
exist.
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 27/01/2012 21:36, Lex Trotman wrote:
Anyway, I don't know how to improve the situation. My commit is necessary to
avoid confusing users about truncation on a local file that doesn't even
No, neither do I, but we do get complaints about truncated files on network shares/gvfs every so often, thats why we added the message.
IIRC I added the message because of unexpected truncation of files on any FS that has run out of space.
So this change actually prevents the message in its main use-case, where harm may have been done, in favour of a use-case where no harm has been done, and that is bad.
Confusing the user is also harm. A (paranoid) user may worry some other file got truncated.
When writing to a networked file I would expect users to take more notice of error messages, i.e. they should expect a save error might cause truncation.
Nick
On Wed, Feb 1, 2012 at 4:14 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 27/01/2012 21:36, Lex Trotman wrote:
Anyway, I don't know how to improve the situation. My commit is necessary to
avoid confusing users about truncation on a local file that doesn't even
No, neither do I, but we do get complaints about truncated files on network shares/gvfs every so often, thats why we added the message.
IIRC I added the message because of unexpected truncation of files on any FS that has run out of space.
It doesn't actually matter what the initial trigger for adding it was, it also indicates harm in the remote case, and one of the (war and peace sized) ML threads was triggered by complaint about truncation of remote files IIRC.
So this change actually prevents the message in its main use-case, where harm may have been done, in favour of a use-case where no harm has been done, and that is bad.
Confusing the user is also harm. A (paranoid) user may worry some other file got truncated.
Ok, better put the filename in the message then, but preventing the message in the case where it is probable that actual harm has been done is really bad.
Cheers Lex
When writing to a networked file I would expect users to take more notice of error messages, i.e. they should expect a save error might cause truncation.
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 31/01/2012 23:09, Lex Trotman wrote:
Confusing the user is also harm. A (paranoid) user may worry some other file
got truncated.
Ok, better put the filename in the message then, but preventing the message in the case where it is probable that actual harm has been done is really bad.
It would still confuse the user. Why tell the user something worrying that may well not be the case?
BTW do you agree/disagree with:
When writing to a networked file I would expect users to take more notice of error messages, i.e. they should expect a save error might cause truncation.
On Thu, Feb 2, 2012 at 3:51 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 31/01/2012 23:09, Lex Trotman wrote:
Confusing the user is also harm. A (paranoid) user may worry some other file
got truncated.
Ok, better put the filename in the message then, but preventing the message in the case where it is probable that actual harm has been done is really bad.
It would still confuse the user. Why tell the user something worrying that may well not be the case?
So why did you add a "may" message in the first place :)
I still contend that it is more bad to hide a possibly valid damage warning than to cause consternation by a possibly invalid message.
BTW do you agree/disagree with:
I'd agree that I (like you) would *expect* it, but sadly I don't think thats the case in the real world.
I'm not sure we can assume all users are fully cogniscent of the fact that things are remote, NFS and samba mounts do a good job of hiding remoteness, but they still fail more often (in my experience) than out of disk happens. And to a user plugging in a NAS device is just the same as plugging in a USB disk isn't it? After all it is attached to the machine? Look its my g: drive!
Come to think of it, USB disks can have the plug bumped etc. There are lots of ways for temporary failures to happen long before we get to things as "exotic" as ssh or ftp connections beneath GVFS mounts that Colomban wants to make easier! (see other thread).
For non-C/system programmers, the idea that a save error could indicate truncation of the existing file can be, at best somewhat hazy, and at worst totally foreign, and Geany has grown way beyond just C/system programmers.
When writing to a networked file I would expect users to take more notice of error messages, i.e. they should expect a save error might cause truncation.
Cheers Lex
On 01/02/2012 23:05, Lex Trotman wrote:
On Thu, Feb 2, 2012 at 3:51 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 31/01/2012 23:09, Lex Trotman wrote:
Confusing the user is also harm. A (paranoid) user may worry some other file
got truncated.
Ok, better put the filename in the message then, but preventing the message in the case where it is probable that actual harm has been done is really bad.
It would still confuse the user. Why tell the user something worrying that may well not be the case?
So why did you add a "may" message in the first place :)
I still contend that it is more bad to hide a possibly valid damage warning than to cause consternation by a possibly invalid message.
BTW do you agree/disagree with:
I'd agree that I (like you) would *expect* it, but sadly I don't think thats the case in the real world.
I'm not sure we can assume all users are fully cogniscent of the fact that things are remote, NFS and samba mounts do a good job of hiding remoteness, but they still fail more often (in my experience) than out of disk happens. And to a user plugging in a NAS device is just the same as plugging in a USB disk isn't it? After all it is attached to the machine? Look its my g: drive!
Come to think of it, USB disks can have the plug bumped etc. There are lots of ways for temporary failures to happen long before we get to things as "exotic" as ssh or ftp connections beneath GVFS mounts
OK, you persuaded me. Reverted.
Nick