GNOME Bugzilla – Bug 317875
GIO/GVfs support
Last modified: 2017-12-13 18:46:25 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.
*** Bug 325192 has been marked as a duplicate of this bug. ***
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.
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
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
Change title. http://en.wikipedia.org/wiki/GVFS is replacing GnomeVFS.
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 .
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.
*** Bug 704382 has been marked as a duplicate of this bug. ***
*** Bug 735262 has been marked as a duplicate of this bug. ***
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.
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).
*** Bug 756265 has been marked as a duplicate of this bug. ***
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
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.
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.
(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):
+ Trace 238013
tab = self.parse_args(command_line)
focus=i == 0,
return window.open_paths(gfiles, **kwargs)
auto_merge=auto_merge)
return self.append_dirdiff(gfiles, auto_compare)
doc.set_locations(dirs)
locations[i] = l.decode(sys.getfilesystemencoding())
> ::: 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.
Created attachment 360708 [details] [review] v2 Patch adding initial support for file URIs
Tracked on LaunchPad.net as https://bugs.launchpad.net/bugs/1335457 . Bug currently exists in Xenial, Artful and Bionic.
Nrbrtx: We don't really care here what "Xenial, Artful and Bionic" are,
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. :)
(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!
-- 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.