Is there an equivalent to --s3-disable-checksum for Jottacloud? I took out a month's sub to test the new Pro plan, but on my first transfer of a 50GB file, it's sitting there for 30 minutes and counting (I assume) calculating the hash. It calculated the hash of a 5GB file within 10 minutes or so, but at this rate it is unusable.
I have not seen any options to disable checksum in the docs so I am assuming Jottacloud doesn't support this, but I want to ask the community anyway just in case someone knows a workaround.
Not sure what sort of computer you are using for testing but it must be something real underpowered. On my 5 years old laptop MD5 calculation of 5GB file takes about 20 seconds. In your case 30GB hashing per hour is maybe slow but I would not call it unusable. You can still process 700GB per 24h.
In case of Jottacloud the MD5 hash is required before upload so initial hashing can not be avoided.
What you can do is to skip post transfer hash checking by using:
--ignore-checksum
Normally rclone will check that the checksums of transferred files match, and give an error "corrupted on transfer" if they don't.
However it means that you risk undetected corrupted transfers.
Well the next transfer was 62GB in two files and took a total of 6.5hrs; the transfer itself was at 10MB/s, so most of that time was taken up by hash checking.
I am using a VPS which by its nature is underpowered.
I feel like it would be helpful if this was mentioned in the rclone docs for jottacloud, which are otherwise very detailed and helpful, something like this:
"Jottacloud requires an MD5 hash to be calculated on the sending machine before uploading a file. This could take a long time on old hardware or low-power VPSs. There is no option to disable this process."
Note that Jottacloud requires the MD5 hash before upload so if the source does not have an MD5 checksum then the file will be cached temporarily on disk (in location given by --temp-dir) before it is uploaded. Small files will be cached in memory - see the --jottacloud-md5-memory-limit flag. When uploading from local disk the source checksum is always available, so this does not apply. Starting with rclone version 1.52 the same is true for encrypted remotes (in older versions the crypt backend would not calculate hashes for uploads from local disk, so the Jottacloud backend had to do it as described above).
Yes but it's not mentioned that this can take a very very long time. It would avoid situations like mine where I was wondering why the transfer is not starting for a long time, looking at logs, finding nothing etc.
Also the documentation is a bit outdated I think as the file does not seem to be "cached temporarily on disk" in temp-dir (I checked, plus I wouldn't have had enough space if it tried to do that), so on checking and not finding it, I initially concluded the problem may not have been hash calculation, but after a while it was the only explanation that made sense.
EDIT: I also found a github issue which mentions fixing the 'hashing on temp disk' issue so that makes more sense now.
Can --ignore-checksum be included in the rclone config file somehow (like disable_checksum = true on s3 remotes) to avoid having to type it every time?