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 317875 - GIO/GVfs support
GIO/GVfs support
Status: RESOLVED OBSOLETE
Product: meld
Classification: Other
Component: general
git master
Other All
: Normal enhancement
: ---
Assigned To: meld-maint
meld-maint
: 325192 704382 735262 756265 (view as bug list)
Depends on:
Blocks: 595137
 
 
Reported: 2005-10-03 22:00 UTC by bob
Modified: 2017-12-13 18:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch adding initial support for file URIs (5.18 KB, patch)
2017-09-23 18:52 UTC, Chris Mayo
none Details | Review
v2 Patch adding initial support for file URIs (25.01 KB, patch)
2017-09-30 19:21 UTC, Chris Mayo
committed Details | Review

Description bob 2005-10-03 22:00:17 UTC
To enhance the functionality of the app to allow local files to be compared with
web based files (http & ftp), without having to download them first.
Comment 1 Stephen Kennedy 2006-05-28 00:14:56 UTC
*** Bug 325192 has been marked as a duplicate of this bug. ***
Comment 2 Glen Johnson 2007-04-24 20:31:51 UTC
This enhancement that would be useful.  I just switched from WindowsXP to Ubuntu 7.04 (feisty) and my work environment includes a number of windows file shares.  I  have to mount these via fstab, or copy the source directory/files to my desktop, in order to compare them.
Comment 3 James 2007-12-30 04:01:22 UTC
If someone will mentor me on how to add this then I will try to write a patch.
I have plenty of experience with python and other languages but not very much with the various gnome libraries and whatnot --let me know
_James purpleidea@gmail.com
Comment 4 James 2007-12-30 04:08:37 UTC
ps: for people reading this, although btw, if you need a temporarily solution you can always mount a remote dir using sshfs http://fuse.sourceforge.net/sshfs.html
and then meld will work on your local dir, since it sees the dir as local... +/-
works well.

_J
Comment 5 Stephen Kennedy 2008-09-03 21:05:47 UTC
Change title. http://en.wikipedia.org/wiki/GVFS is replacing GnomeVFS.
Comment 6 Oliver Gerlich 2009-07-22 12:43:27 UTC
With the change to GVFS, there is now the FUSE bridge available. So as workaround, you can find your GVFS shares as normal directories under ~/.gvfs/ , and Meld should be able to access files from there as usual (albeit slower, maybe).

Btw. this might also help for an actual bugfix... Maybe it's sufficient to display GVFS shares in the file chooser (http://www.pygtk.org/docs/pygtk/class-gtkfilechooser.html#method-gtkfilechooser--set-local-only) and let GIO handle everything?

There are some more details about this at http://blog.fubar.dk/?p=104 .
Comment 7 Kai Willadsen 2009-07-25 00:55:37 UTC
As far as I can tell, the local FUSE mount is an implementation detail of the *nix implementation of GVFS, so we can't rely on it existing. Also, it looks like we would still need to depend on GIO/GVFS in order to use this support (do URI->path translation, etc.). I think this is certainly a good idea for the future, but it doesn't look like there's a quick fix.
Comment 8 Kai Willadsen 2013-07-18 20:59:19 UTC
*** Bug 704382 has been marked as a duplicate of this bug. ***
Comment 9 Kai Willadsen 2014-08-23 22:16:07 UTC
*** Bug 735262 has been marked as a duplicate of this bug. ***
Comment 10 Kai Willadsen 2015-01-10 22:20:35 UTC
We'd get two big wins from consistent GIO use. The first and most obvious is remote filesystem support. The second and just as important is more async IO.

This can also be (mostly) done incrementally in different sections. File comparison would be great to get going for remote use. Folder comparison also for remote use, but the async IO would be a huge win here. Having support for remote VC comparisons would be nice, but probably not as important.
Comment 11 Pietro Battiston 2015-03-17 10:17:20 UTC
People arriving to this page (like me fer minutes ago) possibly ignore the fact that...

meld myfile.py sftp://myremoteserver.mine/home/pietro/myfile.py"

already kind of works, in the sense that the files are correctly shown (although, unless I'm wrong, it is possible to save edits only to the local file).
Comment 12 Kai Willadsen 2015-10-09 20:09:57 UTC
*** Bug 756265 has been marked as a duplicate of this bug. ***
Comment 13 slaxd 2017-08-04 03:44:11 UTC
Error Msg from meld:

Error copying '/media/root/5FDA03906F33F217/SAVE/rsyncTEST-usb/allusers' to '/run/user/0/gvfs/ftp:host=192.168.0.103/var/ftp/ftpd/images/PersistenceUSBs/rsync-meld/allusers'

[Errno 95] Operation not supported: '/run/user/0/gvfs/ftp:host=192.168.0.103/var/ftp/ftpd/images/PersistenceUSBs/rsync-meld/allusers'.

Seems the problem is between fuser and gvfs.  The problem seems not to occur in 3.15.1 but begins being reported in 3.15.2.(the new python ver?)
Solution is a workaround not a fix - files/directories will copy but error is still displayed.

ONE SOLUTION:
https://unix.stackexchange.com/a/77457

One possible solution is using sshfs
https://bugzilla.gnome.org/show_bug.cgi?id=317875#c4
https://peppermintos.net/viewtopic.php?f=35&t=5344

fyi gvfs-commands
https://askubuntu.com/questions/499523/what-is-the-difference-between-gvfs-commands-and-common-commands-like-cat-ls-c

cause:
https://github.com/g2p/bedup/issues/74
https://www.bountysource.com/issues/39167286-cannot-save-to-gvfs-mount
https://www.raditha.com/blog/archives/1749.html


Related Bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=768281
Comment 14 Chris Mayo 2017-09-23 18:52:36 UTC
Created attachment 360306 [details] [review]
Patch adding initial support for file URIs

I would like to use the GVfs admin scheme to change files owned by root (as with gedit).

Patch attached is a way to support URIs for files without having to convert everything (directories look like a lot more work).

Also partially works for sftp scheme - if access is already authorised. Otherwise the username/password dialog is being cancelled. Without this working it's not clear if testing for Gio.FileType.UNKNOWN is a good idea.

To test for a URI it uses if "://" in filename, which might be more robust as a compiled regexp match instead  - which file to put it in (it is used in two places)?

Expect there is a good chance it breaks uses I haven't thought about.
Comment 15 Kai Willadsen 2017-09-23 20:37:02 UTC
Review of attachment 360306 [details] [review]:

Generally speaking, a lot of this looks good to me. However, I'd like to suggest a slightly different way to try and get these changes in. This is a bit more work, but when making changes to the existing code to get gvfs support, I've tried to make each patch make *some* function argument/class attribute was always a URI.

For example, make it such that `FileDiff.set_files()` always gets URIs not paths, change MeldBuffer to have a `uri` instead of (or as well as if needed) a `filename` attribute, and update `MeldWindow.open_paths()` to take only URIs and I... think you'd be mostly there? That last one will be a bit unpleasant, since it will require conversions so that URIs don't hit append_vcview, and make sure that things emitting `open-path` signals used URIs.

Some corner cases to test when making URI changes are drag-and-drop to a pane and loading a comparison from the "Open Recent" menu.

I am extremely keen to get this in. So you're aware though, I won't have much time for Meld over the next few weeks, so I may take a while to get to any patches.

::: meld/filediff.py
@@ +1607,3 @@
         if self.check_save_modified() != Gtk.ResponseType.CANCEL:
             files = [e.get_file() for e in entries]
+            paths = [f.get_uri() if f is not None else f for f in files]

With this kind of change, can you please make sure to rename the variable (e.g., to `uris`).

::: meld/meldapp.py
@@ +351,3 @@
+                    if f.get_uri() is None or (not f.is_native() and
+                        f.query_file_type(Gio.FileQueryInfoFlags.NONE, None) ==
+                            Gio.FileType.DIRECTORY):

Just so I understand what this is doing, this is an additional check that the *current code in master* would be failing? As it is we'll absolutely handle URIs and create a correct folder comparison for e.g., a file:// URI, just not for ftp:// or whatever.

::: meld/meldbuffer.py
@@ +191,3 @@
+            self.filename = value.get_path()
+        else:
+            self.filename = value.get_uri()

I know it's going to require a bunch more changes, but for this kind of change I think I'd prefer that we rename the variable and update (the I think single case?) where we use it as an actual file name.

Also, this is a MeldBuffer which backs a text view; this can never sanely be a directory.
Comment 16 Chris Mayo 2017-09-30 19:20:19 UTC
(In reply to Kai Willadsen from comment #15)

> For example, make it such that `FileDiff.set_files()` always gets URIs not
> paths, change MeldBuffer to have a `uri` instead of (or as well as if
> needed) a `filename` attribute, and update `MeldWindow.open_paths()` to take
> only URIs and I... think you'd be mostly there? That last one will be a bit
> unpleasant, since it will require conversions so that URIs don't hit
> append_vcview, and make sure that things emitting `open-path` signals used
> URIs.

Agreed to not reusing filename. I looked at adding a uri attribute but ends up with so many changes back and forth to GFile I settled on just using the existing gfile property instead (the comment in NewDiffTab.on_button_compare_clicked() suggests this as a way ahead anyway). This also means the "://" in filename tests go away, but obviously touches a bit more code.

> Some corner cases to test when making URI changes are drag-and-drop to a
> pane and loading a comparison from the "Open Recent" menu.

I have changed the comparisons to store uris instead of paths.
I have changed drag-and-drop code but can't figure out how to test - literally were you can drag from and to.

> ::: meld/filediff.py
> @@ +1607,3 @@
>          if self.check_save_modified() != Gtk.ResponseType.CANCEL:
>              files = [e.get_file() for e in entries]
> +            paths = [f.get_uri() if f is not None else f for f in files]
> 
> With this kind of change, can you please make sure to rename the variable
> (e.g., to `uris`).

When I have converted to GFile I have gone ahead and renamed everything to gfile or gfiles.

> 
> ::: meld/meldapp.py
> @@ +351,3 @@
> +                    if f.get_uri() is None or (not f.is_native() and
> +                        f.query_file_type(Gio.FileQueryInfoFlags.NONE,
> None) ==
> +                            Gio.FileType.DIRECTORY):
> 
> Just so I understand what this is doing, this is an additional check that
> the *current code in master* would be failing? As it is we'll absolutely
> handle URIs and create a correct folder comparison for e.g., a file:// URI,
> just not for ftp:// or whatever.

Yes right up to today's 6b7cb302e, plus the rest of the v2 patch, without this check comparing at least one admin:/// directory:

Traceback (most recent call last):
  • File "/usr/lib64/python3.6/site-packages/meld/meldapp.py", line 76 in do_command_line
    tab = self.parse_args(command_line)
  • File "/usr/lib64/python3.6/site-packages/meld/meldapp.py", line 356 in parse_args
    focus=i == 0,
  • File "/usr/lib64/python3.6/site-packages/meld/meldapp.py", line 155 in open_files
    return window.open_paths(gfiles, **kwargs)
  • File "/usr/lib64/python3.6/site-packages/meld/meldwindow.py", line 673 in open_paths
    auto_merge=auto_merge)
  • File "/usr/lib64/python3.6/site-packages/meld/meldwindow.py", line 616 in append_diff
    return self.append_dirdiff(gfiles, auto_compare)
  • File "/usr/lib64/python3.6/site-packages/meld/meldwindow.py", line 574 in append_dirdiff
    doc.set_locations(dirs)
  • File "/usr/lib64/python3.6/site-packages/meld/dirdiff.py", line 625 in set_locations
    locations[i] = l.decode(sys.getfilesystemencoding())
AttributeError: 'NoneType' object has no attribute 'decode'

> ::: meld/meldbuffer.py
> @@ +191,3 @@
> +            self.filename = value.get_path()
> +        else:
> +            self.filename = value.get_uri()
> 
> I know it's going to require a bunch more changes, but for this kind of
> change I think I'd prefer that we rename the variable and update (the I
> think single case?) where we use it as an actual file name.

Reverted back to:
   self.filename = value.get_path() if value else None


I've tried quite a few scenarios but more testing needed I'm sure.


For fileentry I have experimented with non-local-only GtkFileChooser but the button label just shows "(None)" and clicking on it didn't always show the directory. More to investigate there.
Comment 17 Chris Mayo 2017-09-30 19:21:29 UTC
Created attachment 360708 [details] [review]
v2 Patch adding initial support for file URIs
Comment 18 Nrbrtx 2017-11-07 19:46:23 UTC
Tracked on LaunchPad.net as  https://bugs.launchpad.net/bugs/1335457 . Bug currently exists in Xenial, Artful and Bionic.
Comment 19 André Klapper 2017-11-07 20:27:42 UTC
Nrbrtx: We don't really care here what "Xenial, Artful and Bionic" are,
Comment 20 André Klapper 2017-11-07 20:28:55 UTC
Oops, sorry, let's try again:
Nrbrtx: We don't really care here what "Xenial, Artful and Bionic" are as there are gazillions of distributions and even more distribution versions out there, but you are free to add downstream bug tracker URLs in the "See Also" field. :)
Comment 21 Kai Willadsen 2017-11-18 21:48:27 UTC
(In reply to Chris Mayo from comment #17)
> Created attachment 360708 [details] [review] [review]
> v2 Patch adding initial support for file URIs

Thanks very much, I've pushed this to master now. I noticed a small problem when creating comparisons with a missing selection, and that's now fixed. I'm sorry for the delay here; I got distracted trying to get some mypy type checking happening to help confirm the refactor, but that hasn't happened yet.

I haven't spent any more time looking at other enhancements. I suspect your TODO comment about shorten_names() shouldn't really be needed any more, since I've fixed the relevant usage in `meld.recent`. The other points are still very much valid though.

For future changes here, I think it's worth not being too afraid of reworking path-based internal APIs to be Gio.File based. In almost all cases, this is what we want.

Thanks again for working on this!
Comment 22 GNOME Infrastructure Team 2017-12-13 18:46:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/8.