Jürgen Hötzel <[email protected]> writes:

> Hi Michael

Hi Jürgen,

> Done. `process-environment' is dynamic bound there, so this should not
> have any impact on
> other uses of `process-environment'. 

Thanks.

>     Btw, I'm curious what you plan with google-drive backend and
>     tramp-gvfs.el. A while ago I was thinking about adding a "gd"
>     method,
>     but there was no time / not enough motivation yet to start with.
>
> It's not a specific google-drive backend. Just another gvfs-backend:
> You need to install gvfs-google and gvfs-goa (Google online accounts).
> Of course you have to setup your Google online account in Gnome 3.18.
>
> It already works for me.

How do you access the files then via Tramp? I thought there must be at
least a proper connection method, say "gd". Then you access via
"/gd:[email protected]:/0B9J_DkziBDRFTj1TPam9kbnc/0B9J_GlyfBDRBHj1TRWL9khrc" or
"/gd:[email protected]:/id1/id2/some-title" (example from the artice below).

> The only problem is the non-posix-semantic of
> Google Drive paths
> (https://debarshiray.wordpress.com/2015/09/13/google-drive-and-gnome-what-is-a-volatile-path/):

Yes, when I thought about a google drive Tramp connection method, I read
this article as well. Interesting.

> Each file is identified by a unique blob-id and not by its path. So
> users justs see the blob-id's in directory listings.
> Tramp-gvfs could use the file-attribute
>
> display name: IMAG0260.jpg
>
> (like its done in the gnome file browser Nautilus) to translate
> between display-names and the blob-id. What do you think about it?

Using display name would be OK. Play with tramp-gvfs.el; there's plenty
of time before Tramp 2.2.13 will be released. I plan it for the end of
the year.

> Regards, 

Best regards, Michael.

_______________________________________________
Tramp-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/tramp-devel

Reply via email to