Also the data is not encrypted, this is in my opinion a high risk in itself. The company claims in big letters on their home page that data is "safely stored". I asked several times if they found the error, but according to them they they never did. As a solution they offered to delete my entire account and that I re-upload the data to their servers, plus one year without billing for the backup service. I needed to restore some files from their service, and after downloading I discovered that seemingly random files had erroneously a size of 0 bytes. I lost lots of family photos because of this. Jottacloud actually corrupted 26 000 files in my backup set. I'd advise you not to gamble the safety of your data on this company. In these abovementioned cases, we reserve the right to offer an alternative Jottacloud subscription, cancel the subscription, or in some cases delete the user account and/or user data." Beware that the notice they give once they decide you've made "too much" use of their "unlimited" offer, may not be long enough for you to recover your data from their hands before they delete it. If a user’s total storage and network usage greatly exceeds the normal usage of an average Jottacloud user, and/or indicates that the Service is being uses for other than normal individual and non-commercial use, this may be deemed as abuse of the Service. Taken from their TOS: "We reserve the right to limit excessive use and abuse of the Service. According to their terms of service it's only possible for a user to use unlimited storage space if the average user uses unlimited storage space, which is an absurd reality and (surely) Jottacloud knows that. Their use of "Unlimited" is a marketing lie. 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 (wherever the TMPDIR environment variable points to) before it is uploaded.Do not believe their abuse of the word "Unlimited" Jottacloud supports MD5 type hashes, so you can use the -checksum flag. In my case, my SD card has little space and I have multiple external drives and therefore want to set $TMPDIR to a specific folder on separate drives when I copy. If you ask me, this should be mentioned just below configuration with an example on how to solve this. So, I highly recommend adding a bigger NOTE at so people that use crypt and have limited storage space for the /tmp folder can easily spot this issue. In addition to that, I tried to change the tmp-dir with -cache-tmp-upload-path. Especially frustrating was the part that I thought not using -c should solve this, as well as using -ignore-checksum. I had an unfortunate start with rclone and Jottacloud as this issue has bothered me for many hours without figuring out why I was seeing TIMESTAMP ERROR : FILE: Failed to copy: failed to calculate MD5: write /tmp/rclone-*md5-*: no space left on device. Providing a cut down interface Rewind (say) would be much easier - maybe that is the way to go. The encryptor with seek would be equally challenging. Crypt has a file decryptor with Seek capability and that was extremely challenging to get correct. If the io.Seeker wasn't available it would do what it does at the moment. Then the jottacloud backend would be able to do a type assertion for io.Seeker and if found it could read the file to make the MD5, seek, then read it again. all the accounting gubbins for uploads implements io.Seeker.local upload streams implement io.Seeker. crypt upload streams implement io.Seeker.The only way this could possibly work is if One thing to bear in mind is that encrypting the same file twice won't get the same result (becuase of the nonce at the start of the file) so this needs to be done in the same encryption stream. Rclone uses a streamed architecture for transferring files so the backends don't get files to upload, they get file streams (an io.Reader in go speak). Alas this is a lot harder than it appears!
0 Comments
Leave a Reply. |