GNU bug report logs - #64278
29.0.92; tramp-rclone.el seems to be in a defunct state

Previous Next

Full log

Message #14 received at 64278 <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Miele <iota <at> whxvd.name>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 64278 <at> debbugs.gnu.org
Subject: Re: bug#64278: 29.0.92; tramp-rclone.el seems to be in a defunct state
Date: Sun, 25 Jun 2023 19:45:53 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Sun, 2023-06-25 14:55 +0200
>
> I've never tried the memory type of rclone. I have two test entries in
> ~/.config/rclone/rclone.conf:
>
> [local_drive]
> type = local
> nounc = true
>
> [gdrive]
> type = drive
> scope = drive
> ...
>
>
> Both work, and they are tested regularly in my regression tests. So I
> wouldn't say that tramp-rclone.el is in a defunct state.

I clearly was under a false impression. :-)

>> […]
>
> Reproduced here. I've pushed a fix to the emacs-29 branch in git.
>
> Furthermore, there is indeed a problem detecting a mount point for
> rclone memory type. The appended patch should fix this.

Thanks a lot!

With both, the fix on the emacs-29 branch, and after applying the patch,
everything works for me.

The problem the patch addresses is not relevant at least for Rclone
remotes of type local.  I didn't try Google Drive.  However, the patch
also is necessary for Rclone remotes of type webdav.  I have

  [wolke]
  type = webdav
  url = https://…
  vendor = other
  user = …
  pass = …

and ‘mount -t fuse.rclone’ yields:

  wolke: on /tmp/tramp.rclone.wolke type fuse.rclone …

I.e., at least this WebDAV remote makes Rclone omit the "/", too.
Because of that, I think the patch should be applied upstream.

> However, calling "emacs /rclone:memory:" with the rclone.conf entry
> given by you.conf results in in an empty directory. No file visible
> there, even if I copy something.
>
> I've tried the rclone memory type manually in a shell
>
> # mount -t fuse.rclone
> local_drive:/ on /tmp/tramp.rclone.local_drive type fuse.rclone (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> memory: on /tmp/tramp.rclone.memory type fuse.rclone (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
>
> # ls -al /tmp/tramp.rclone.memory
> total 0
> drwxr-xr-x.  1 albinus albinus    0 Jun 25 14:49 .
> drwxrwxrwt. 99 root    root    7800 Jun 25 14:49 ..
>
> # rclone copyto ~/tmp memory:
>
> # ls -al /tmp/tramp.rclone.memory
> total 0
> drwxr-xr-x.  1 albinus albinus    0 Jun 25 14:49 .
> drwxrwxrwt. 99 root    root    7800 Jun 25 14:51 ..
>
> So I'm a little bit undecided what the memory type of rclone is good
> for, and how it works. Do I miss something?

I could not create files in an Rclone remote of type memory, either.
Didn't notice that before reporting the bug.  There is no real use case
for the memory provider, except for debugging.  For me, it was all about
WebDAV, and after the fix and the patch, that works.

Thank you!

Best wishes
Sebastian

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.