OS: Debian 10 x86 64bit
remote: Google Drive
I am trying to see if it's possible to upload a file to two directories without uploading the same file twice.
in the same remote. Copying it from the remote somewhere else in the remote counts as GDrive internal BW (at least from my tests). Is there some way of doing this automatically with rclone after the file has been copied on the first target? So copy it to remote: and afterwards copy it to remote:2nd
-- If this is possible I could exclude B from appearing when the remote is mounted with --exclude "/2nd/**" correct?
different remote same google account, SA etc - I believe this is not possible.
using cp on a cached mount appears to re-upload the file
--drive-server-side-across-config works perfectly if it's used on unencrypted remotes.
I am trying to use it on two encrypted mounts though. I created the second crypt remote by copying the first as to keep the encryption settings and passwords the same. The drive remotes are identical just use different SA (on which --drive-server-side-across-config works fine).
It always just downloads from the 1st and uploads it to the 2nd. What am I missing?
if both remotes use the same encryption settings, then you can use --drive-server-side-across-config.
you can copy the encrypted files from the remote to remote.
source remote is remote1:encbucket
you have created an encrypted remote named secret1: on remote1:encbucket
the dest remote is remote2:encbucket
you have created an encrypted remote named secret2: on remote2:encbucket
if you rclone copy secret1: secret2:, then rclone will have to
download the file from secret1:
decrypt the file based on secret1: encryption settings
encrypt the file based on secret2: encryption settings
upload file to secret2:
to be clear, rclone will not have to download the entire file, instead rclone will download a chunk at time, process that chunk and upload the chunk.
now if the encryption settings are the same for secret1: and secret2: then rclone copy remote1:encbucket remote2:encbucket --drive-server-side-across-config
will not download the files to local computer.
He could copy them at the unencrypted layer though. He could script a way to pull the lower level file name and copy. Assuming he wants the same nonce on both. I do all my syncs at the lower level to me backup drives.
I understand that, but if the two encrypted remotes have the same passwords, then it means the encryption is the same, which is valid since by copying the crypt remote to a new one and using it to ls I can see the contents.
@asdffdsa I am doing exactly that. I copied secret1 to secret2
rclone copy secret1: to secret2: will force rclone to download and upload files.
but if you just copy the already encrypted files from the folders that secret1: and secret2: are based on rclone copy remote1:encbucket remote2:encbucket --drive-server-side-across-config
then nothing needs to be downloaded and nothing needs to be decrypted and encrypted and uploaded
I might be trying to make a lot of assumptions but please hear me out:
Server side copy encrypted files using the same crypt remote works fine
If I copy that remote and just change it's name, it's basically 100% the same remote
therefore (assumption) it should still work? Can it be that since normally almost all the encrypted remotes will have been setup with different passwords --> encryption used the default action is to fail without any check? Or doing said check would be difficult (outside comparing the password values in the config for the different mounts).
If that is true would it be possible to have a flag that attempts to copy them without trying to decrypt/encrypt with the users responsibility?
Why would you want to build additional code/logic for functionality that already exists?
You can do what you are asking by using the non encrypted remotes. Not sure the time/value add for adding that to the encrypted remote sections. You can always add a feature request on GitHub and it can be worked on or you can add it yourself and do a pull request if you find it valuable as well.
Honestly? Cause I don't really like the idea of having to call a script to identify the encrypted path from them decrypted ones.
But I respect the fact this is a niche request, there is a viable alternative and the above would require time from the devs, so I 'll pick calisro's answer as the solution and think whether this really merits a github request (even if it's a low urgency one)