Re: Rclone?

[Matt M]

Michael,

You are a superstar.

Mostly what I do daily with rclone is:
- ls (cli & macos finder using a mount)
- copy* (copy from, really; finder+mount)
- delete (finder+mount)
- rename (aka move, finder+mount)
- sync* (cli -- I sync between multiple clouds, redundacy)
- move* (cli)
- moveto* (cli)

The move/moveto/sync/copy can take a long time, and are prone to errors (like 
cloud storage needing its garbage bin dumped), so having "progress" feedback is 
nice using -v,  And of course, error feedback is very important, regardless of 
flags.

Also, those commands can use lots of bandwidth, so I usually limit that with 
--bwlimit.  Otherwise, you may find your internet to be otherwise unusable for 
extended periods.  However, I do NOT limit bandwidth when copying down, as it 
is very tough for me to use up my download bandwidth.  YMMV.

Those are really the only 2 flags I use.

I will give it a spin when I get time.  U.S. holiday, though ...
(Also, I have no experience comparing tramp w/native.)

Thanks!
-- Matt

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, November 22, 2018 7:42 AM, Michael Albinus <address@hidden> wrote:

> Hi Matt,
>
> I have pushed some further patches to the Tramp repo. Everything is
> still experimental, but my major concern is performance. Do you have
> some experience, comparing native rclone operations, and Tramp's
> integration?
>
> Furthermore I'm planning to push this also to the Emacs
> repository. Maybe there are some further rclone aficiliados, who could
> give early feedback. Anybody reading this here on the Tramp ML is
> invited for testing as well!
>
> I have tested it so far only with Google Drive and the local
> filesystem. Likely, there are some flags or so one needs to consider for
> these or other file systems. For the time being I don't use any specific
> flag; but I have the feeling we should allow this for users.
>
> What do you think about?
>
> Best regards, Michael.