Load the whole file tree of a just-mounted remote

I think @asdffdsa already asked this question but I am also curious. Why to use proton drive? It is slow and expensive ($8.6 per TB per month with their most economical plan) compared to other options. Also when you read rclone PRs it makes it very clear why it is marked as beta - it is not open source nor use any open protocols. Somebody was kind or curious enough to do a lot of work to make it work but it is far from being solid solution - at least yet. And when this person one day lose interest it will rot to death as it is not something supported by any wider community.

Is it some sort of fashion? Does it have any advantages vs Wasabi or iDrive or even OneDrive?

Honestly? I love Proton. I use ProtonMail, ProtonCalendar, ProtonPass and ProtonVPN, which are all outstanding. So I want to support their effort with their newcomer ProtonDrive, help them make it better, show that people are interested in their work, and push them to develop ProtonDrive into a full and complete solution on par with Google Drive, OneDrive (which I hate because it never worked correctly for me and I don't want to depend on Microsoft), and Mega and the others.

TLDR: I want to support the ProtonDrive program, so that Proton can propose a coherent, full ecosystem of services.

1 Like

Fair enough:) Thank you for your answer. And good luck for this project.

1 Like

me too, i do have a paid account.

To achieve your goal, proton needs to open their api, then rclone would not have to depend on third-party libraries that seem not to have been updated in over 8 months, decrease api calls delays and support ListR

Perhaps contact proton and ask them to sponsor rclone?

1 Like

Yes that might be something to put in the vote section of Proton Drive suggestions :slightly_smiling_face: back me up when I do it!

But I would prefer a Linux desktop client, by far.

SOLUTION:

Here's my setup now: $P is the folder I mount my remote Proton Drive in.

  1. First run:
rcmount proton: $P --rc --rc-addr 127.0.0.1:5572 &> $LOG/.proton_live.log &
  1. Then:
rclone rc vfs/refresh recursive=true --url 127.0.0.1:5572 _async=true &>> $LOG/.proton_live.log

...but I'm not sure that one is doing much. (★)
3. And finally, open a new terminal tab and run the command:

ls -R $P

...and let it run in the background, forget about this terminal.

(★): Fortunately, if a change doesn't propagate fast enough, I wrote this script (which is meant to be run in the directory where the change is expected):

echo $PWD > .temp
sed -i 's/$P\///g' .temp
location="$(cat .temp)"
rm .temp
rclone rc vfs/refresh recursive=true --url 127.0.0.1:5572 dir="$location"

There seems to be a limit to this script though, when I run it multiple times I get the output:

 rclone rc vfs/refresh recursive=true --url 127.0.0.1:5572 dir=$location
{
        "result": {
                "$location": "failed to refresh auth: failed to refresh auth, de-auth: 400 POST https://mail.proton.me/api/auth/v4/refresh: Invalid refresh token (Code=10013, Status=400)"
        }
}

I don't know how to solve this last problem, but I think this comment covers enough solutions to be marked as solution (?) so that's what I'll do, and tell me if I shouldn't.

1 Like

sure, post a link and i will vote on it for you.

tho, i would never used it.
i am not a fan of full ecosystem of services. in the respect, proton is no different than google or micro$soft.
i use proton mail. instead of protonvpn, i use mullvad. instead of the protonpass, i use keepass, etc....

1 Like

IMO step (2) and (3) are doing exactly the same....

For step (2) you can check if it is finished by running

rclone rc --url 127.0.0.1:5572 --json '{ "jobid":nn}' job/status

where nn is jobid you should get from step (2)

As rclone proton remote today is not the fastest it can take time.

Using this status of vfs/refresh you could also avoid running multiple instances of it which probably results in error you mentioned. Probably something to do with "overloading" proton API.

Instead of job/status you could also use job/list (as only jobs you have are refresh ones) and delay subsequent vfs/refresh until other is finished.

I'm sorry I didn't understand your explaination... Could you please post the full command(s) you would use in that situation? (that's not me being lazy I just don't get it)
Please :slightly_smiling_face:

Run:

  1. mount - it starts your mount with rc server listening to remote commands
rclone mount remote: mountPoint --rc --rc-addr 127.0.0.1:5572 --rc-no-auth
  1. initiate vfs/refresh - it outputs job ID - capture it and use in the next step
$ rclone rc vfs/refresh recursive=true --url 127.0.0.1:5572 _async=true
{
	"jobid": 1
}
  1. job/status - it will tell you what is the status of your job id

still running as you can see "finished": false:

$ rclone rc --url 127.0.0.1:5572 --json '{ "jobid":1}' job/status
{
	"duration": 0,
	"endTime": "0001-01-01T00:00:00Z",
	"error": "",
	"finished": false,
	"group": "job/1",
	"id": 1,
	"output": null,
	"startTime": "2023-11-06T20:33:39.455784Z",
	"success": false
}

checking, checking until finished - until "finished": true and all other details:

$ rclone rc --url 127.0.0.1:5572 --json '{ "jobid":1}' job/status
{
	"duration": 160.298011965,
	"endTime": "2023-11-06T20:36:19.752927Z",
	"error": "",
	"finished": true,
	"group": "job/1",
	"id": 1,
	"output": {
		"result": {
			"": "OK"
		}
	},
	"startTime": "2023-11-06T20:33:39.455784Z",
	"success": true
}

You have to check job status within 60s before it is done - as then job status will be purged.

You can change it if not enough time using --rc-job-expire-duration flag when you start you rc server (in rclone mount command)

You have basics working already - now time to give it some sophistication:)

Also to give you some benchmark you can see that my vfs/refresh job finished in 160 seconds - it is for remote with 500k files - this is why I consider Proton painfully slow.

1 Like

Going this path for sure you can build working solution but it won't be straightforward - depends if you care more about the goal or just enjoy the journey:)

The best way forward would be to get involved (either hands on or lobbing or both) in Proton rclone remote development and push for ListR and polling support. When these two features are supported it will all become very easy and fast.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.