"Unlimited" alternatives to Google Drive, what are the options?

[dia3olik]

@mvjunkie

ive been hearing European customers experience super slow speeds.

Anyone from EU that can chime on this? Are the speeds really that slow?

[quote="mvjunkie, post:385, topic:36529"]Also, what is the chunker command to clean out unused chunks? Ive had to stop uploads and resume on many occasions.
[/quote]

Yeah! I'm interested in this too

[haig233 (yang liu)]

I'm already working on Box's enterprise plan, and the slow running speed is only because Box limits the number of API calls (at least, it is stricter than Google Drive's limit), and the number of calls is limited, so the speed will naturally slow down ( It may be the reason why a large number of multi-threaded operations cannot be performed), generally speaking, the impact is not too great, especially now that there is only one option for unlimited storage left.

[ralf2105]

I can not confirm. I'm uploading with 2 different vps from the Netherlands with a total of 200mb/second. But the upload per file is mostly between 8-15mb/sec. I have raised the maximum data transfer. A testdowload of a larger file gave 170-190mb/sec. In a conversation with the support I was told that the maximum API calls may be exceeded at the beginning, only when longer exceed Box then reports to a personal. But no access will be restricted if the limit is exceeded. Also, the API limit can be increased permanently for a surcharge. Rclone chunk with 49Gi works perfectly for me.

[haig233 (yang liu)]

The reply from the customer service means: the number of API calls will not continue to be limited, but will surcharges be added to the bill?

[ralf2105]

Is not known to me. There is no price list and even the sales team could not give me a price. Also, Box will contact you beforehand.

[kapitainsky]

@mvjunkie

Also, what is the chunker command to clean out unused chunks? Ive had to stop uploads and resume on many occasions.

As it might be useful for other people I have created Howto Guide:

Chunker remote - how to clean orphaned chunks

Chunker remote works perfectly but misses resume functionality. It means that if your many chunks upload is interrupted and you start again everything will have to be re-uploaded. Worse still is that previously uploaded chunks will be left behind... and stay there forever invisible for chunker remote unless you manually clean them in underlying remote. It happens because all chunks during upload are stored with random suffix - only renamed when all file is uploaded (making all operation sort of…

[Rootax]

I guess that, like Dropbox, the // chunck uploading is not implemented so yeah, single file upload is only using one stream/connection, which depend on a lot of parameters to be fast like latency, packet loss, congestion managment, etc.

[kapitainsky]

It is actually implemented. But in kinda weird way...

Box.com Mult-Part Multiple Uploads

I understand that if I'm copying say a single file, and do --transfers=50, it will do multiple multi-part uploads on that single file, and speeds up uploads significantly. This is using box.com How would I go about upping the amount of multi-part uploads, without increasing the amount of files that are copied? In a folder that has say 100 files in it, and I'd like to upload say 4 at a time, but allow up to XX part uploads, what would be the options to do this? I understand this increases RAM u…

[Rootax]

Indeed, I stand corrected / --box-upload-cutoff is a nice option to have.

[Turner]

Currently at 30TB with Box, speeds have been consistent, and no warnings of space usage, or API limits.
I did have to update the Crypt option to a base32768, otherwise I was getting filename too long errors.

[ralf2105]

Can you tell me what you change in the crypt option? I get the error message too.

[Turner]

It would be the --crypt-filename-encoding in the config file, or within the advanced options of the rclone configuration tool for that specific crypt mount.

I believe changing it while data exists, may make the existing data inaccessible. I started over after making the change.

[kapitainsky]

I suggest you test first if base32768 works - it should but it has been really only tested on dropbox and onedrive.

It requires remote to correctly handle all 32k characters used.

You could use this file - base32768.zip - it contains files with all base32768 characters. To test you have to copy them to box remote (not crypt) and then maybe run rclone check to see if nothing changed.

Would be great if you share results - so we can update crypt documentation and mention there that base32768 works on box.

[Turner]

I gotchu, give me a few.

[Turner]

Uploaded successfully, no errors, I then ran rclone check. Please let me know if there are other flags I need to attach to rclone check.

[kapitainsky]

This is very good.

One more thing - could you please run:

rclone test info --check-length boxremote:

and post results here? It takes maybe 2-3 minutes to run as it empirically tries to discover what is allowed and what is not.

We want to see how box count characters - as characters or bytes - base32768 is using UTF16 (2 bytes encoding)

[Turner]

@kapitainsky

rclone test info --check-length

[kapitainsky]

OK - so max file length is the same for 1 byte and 2 byte encoding. This remote is perfect for base32768.

base32768 actually shortens file names in most cases so is the best choice for supported remotes. Google has insane max path length (4k I think - it was no issue to use default base32 used by crypt) so easy to encounter problems moving to more limited remotes. Box I think is 1024 - but onedrive is only 400

[Turner]

Yeah I tried base64 and it was working, but figured why not go all the way!
Glad it's up to snuff!

[kapitainsky]

On top of my head:

base32 - 150% of original string length
base64 - 120%
base32768 - 51%

so yes if base32768 is supported it is only logical choice.