After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774235 - Cannot save to gvfs mount
Cannot save to gvfs mount
Status: RESOLVED INVALID
Product: meld
Classification: Other
Component: general
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2016-11-10 23:05 UTC by Brian
Modified: 2016-11-13 20:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to make this issue always show error message (no silent saving fail) (3.78 KB, patch)
2016-11-11 19:36 UTC, Vasily Galkin
none Details | Review
Patch to make this issue always show error message (no silent saving fail) (4.12 KB, patch)
2016-11-13 01:07 UTC, Vasily Galkin
none Details | Review

Description Brian 2016-11-10 23:05:00 UTC
IIRC before I upgraded to Ubuntu 16.10 (which upgraded my copy of meld) I was able to save files located in a gvfs (sftp) mount. I don't recall what version I had previously, but the error I get when trying to save within meld is:

Couldn't save file due to: g-io-error-quark: Error opening file '/home/mscdex/sftp_mounts/sftp:host=somehost/path/to/file/being/saved': Operation not supported (15)

I tried searching for the error but didn't really come up with a whole lot. I should note that the 'sftp_mounts' in my home directory is actually a symlink to '/run/user/1000/gvfs/' for convenience. It does not appear to be a permission issue since I can save to the exact same file in my text editor, which is exactly what I'm having to do right now if I need to copy changes over from the diff.

On an unrelated note, it would be nice to be able to highlight and copy error messages from error popup windows...
Comment 1 Brian 2016-11-10 23:16:15 UTC
I've been able to narrow down the breakage to have happened between 3.15.1 and 3.15.2.
Comment 2 Brian 2016-11-10 23:30:39 UTC
bisecting reveals ffd28fcd4ad08be928d9d4aa8a0a4dae04916a71 is the first bad commit
Comment 3 Vasily Galkin 2016-11-11 19:36:10 UTC
Created attachment 339666 [details] [review]
Patch to make this issue always show error message (no silent saving fail)

I tried to reproduce this issue and it looks to be glib-or-gtksource related problem with handling symbolic links to gvfs mounts in glib applications.

The file ~/symlink-to-run-user-1000-gvfs/sftp\:host\=localhost/tmp/README
can be saved with vim editor, but can't with meld and gedit.

Symbolic links or gvfs mounts without each other are working fine.

By the way while tring to reproduce this issue I found that no error message appears while file wasn't saved and save icon was left in enabled state.

It revealed  that lots of error messages are just lost in meld 3.16 due to encoding problems if glib returns error message translated to non-ascii language, because python tries to use ascii codec on uncide + str concatenation and formatting.

Attaching patch to fix displaying of several error messages.
Comment 4 Kai Willadsen 2016-11-11 22:41:34 UTC
(In reply to Brian from comment #0)
> On an unrelated note, it would be nice to be able to highlight and copy
> error messages from error popup windows...

Unfortunately, this appears to be a GTK+ change. In my testing, copying text from GtkMessageDialogs works fine in GTK+ 3.18 and fails in 3.20. I haven't tested 3.22.

(In reply to Vasily Galkin from comment #3)
> The file ~/symlink-to-run-user-1000-gvfs/sftp\:host\=localhost/tmp/README
> can be saved with vim editor, but can't with meld and gedit.

(In reply to Brian from comment #2)
> bisecting reveals ffd28fcd4ad08be928d9d4aa8a0a4dae04916a71 is the first bad
> commit

This makes sense, since the bisected commit is the one where we switched over to using GtkSourceView's file loader + saver. Can I ask that you please file a bug against GtkSourceView, if Vasily's description seems to be what you're seeing?
Comment 5 Kai Willadsen 2016-11-11 22:45:54 UTC
Review of attachment 339666 [details] [review]:

Minor comment below, but otherwise this all looks good to me, thanks!

Best I can tell, I wouldn't expect any of these issues to show up in current master with the python 3 changes. I don't suppose you've tested this?

::: meld/dirdiff.py
@@ +964,3 @@
+                    msg = err.message.encode('utf8', 'replace')
+                else:
+                    msg = str(err)

Can we do an isinstance(err.message, unicode) style check instead here? It feels weird to me to special-case the exception itself.
Comment 6 Vasily Galkin 2016-11-12 23:52:49 UTC
> Best I can tell, I wouldn't expect any of these issues to show up in current
> master with the python 3 changes. I don't suppose you've tested this?

I tested current master in a sketchy way and didn't see any exception related to similar error messages, all of them were displayed. So it looks fine Though I didn't test current master behavior with symlink-to-gvfs-mount situation described in this bug.
Comment 7 Vasily Galkin 2016-11-13 01:07:17 UTC
Created attachment 339730 [details] [review]
Patch to make this issue always show error message (no silent saving fail)

Converted patch to checking type of args[0] property.

Not the message property, because according to http://legacy.python.org/dev/peps/pep-0352/#transition-plan it looks that message property was deprecated since python2.6 and it is not clear why current python2.7 doesn't give a deprecation warning about it.

Also some explanations were added to commit text.
Comment 8 Brian 2016-11-13 01:36:45 UTC
I've submitted an upstream bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=774303
Comment 9 Kai Willadsen 2016-11-13 20:19:51 UTC
(In reply to Vasily Galkin from comment #7)
> Created attachment 339730 [details] [review] [review]
> Patch to make this issue always show error message (no silent saving fail)
> 
> Converted patch to checking type of args[0] property.
> 
> Not the message property, because according to
> http://legacy.python.org/dev/peps/pep-0352/#transition-plan it looks that
> message property was deprecated since python2.6 and it is not clear why
> current python2.7 doesn't give a deprecation warning about it.
> 
> Also some explanations were added to commit text.

Looks good to me. I've just pushed this to the 3.16 branch. Thanks again!

(In reply to Brian from comment #8)
> I've submitted an upstream bug report here:
> https://bugzilla.gnome.org/show_bug.cgi?id=774303

Thanks for that. If after that fix we're still doing something wrong, please feel free to reopen this. In the meantime, I'm going to close this bug.