@ncw What are crypt limitations?

Since crypt does not support checksum/hash what rclone features we cant use or wont be as efficient as they would be with remote that support hash.

For example:
If we rename files files on source and use sync with crypt remote the files will always be downloaded/uploaded, however without crypt the files would be just renamed without any transfer. ( is there was way to make this working with crypt drive and without hash )

Iam pretty sure there were some other limitations as well but just cant remember what was it.

I think I got around that by using both mounted directories or maybe the dest wasn’t encrypted. :stuck_out_tongue_winking_eye: So vs doing something like rclone sync m: t: it was something like rclone sync /path/to/mount /path/to/dest/mount.

It may also have ran into that bug where it actually deletes the directory. It was a total mess since there server thousands of files that needed to be renamed. I think I just ended up copying it all up since it was hard to track what was what at that point.

But yeah I think having some sort of crypt limitation table would be helpful.

Crypt will support whatever the underlying remote supports in terms of server side copy, renames etc - see the table here: http://rclone.org/overview/#optional-features and here http://rclone.org/overview/#features

Exceptions are

  • Crypt does not support hashes
  • Crypt remotes will be case sensitive even on a case insensitive remote if file name encryption is used
  • File name length limitations for encrypted file names - crypt expands the length of file names by 8/5 roughly so you may hit limits you weren’t hitting before

Not supporting hashes means that --track-renames doesn’t work and rclone check doesn’t do a particularly thorough job.

It would be possible - rclone could read the first 1k of the file over the network and make a hash of that instead which might be good enough for most purposes.

So --track-renames is the only thing not working.
As for rclone check in my cases having acd and backup on gdrive should work just fine if the check is preformed directly on already encrypted files eg rclone check acd:/crypt gdrive/crypt ( basically where acdcrypt path is )

1 Like

Yes that will work - good thinking!

For reference in case people view this thread later…

The comment by @Ajki above will only work if you are using the same passphrase on both remotes. If you choose a different passphrase then this will not work.

@ncw

Would it be worth adding this to the documentation?

Fancy sending a pull request with some suggested text? Or just post it here if you want.