Before transferring a file, we compare the new file to the previous version and only send the piece of the file that changed. This is called a “binary diff” and works on any file type. Dropbox compresses files (without any loss of data or quality) before transferring them as well. This way, you also never have to worry about Dropbox re-uploading a file or wasting bandwidth.
Hi @Zero_G,
Dropbox doesn’t support their “binary diff” transfer via their API, so it is not possible for integrators like us to utilize that.
I can’t speak to the client-side compression they are performing on their own client, but the odrive client supports standard HTTP compression for transmission, and this may be what they are talking about when they state that they compress files before transferring.
Any versioning or compression they do on the remote storage side stays the same, since they are handling that on the service side, after receiving the data.
So if I’m exporting a large file (say a 200MB render from Premiere) to an odrive-synced folder, and the file takes 30 minutes to create … does odrive wait until it’s done? Or restart the upload after every write?
odrive tries to detect if the file has changed. If the application buffers the output before writing to disk, so that there are long-ish gaps between writes to the disk, odrive may start uploading it and then stop when it sees the size has changed.
Best strategy is probably to stop sync until the export is done (under “Ready to sync changes”/“Syncing changes”). odrive will try to account for the changes, though.
I’ve had similar issues in other cloud providers. I will be writing a file to a directory, it will start to upload…and the date in the cloud is newer than on the computer…so in the sync it then starts to pull down the incomplete file and overwrites the one locally…it ends in total disaster.
I would make sure it’s done locally first, then copy or move to odrive.
As @JamesGTRS said, it is always best to make sure things are 100% complete locally before trying to upload them.
In the situation where a new remote file shows up before the local file uploads, odrive has conflict detection to avoid losing anything by creating a conflict copy.
This really sucks! I just uploaded a 40GB file, changed 1 byte in that file and now the whole thing is uploading again. Is it just the dropbox desktop app that supports this binary diff ?
If I split the files into parts using odrive will that take care of this issue?
Dropbox doesn’t support this via their API, so we have no way to make use of their binary diff method.
IFS will help to upload large files, but it will not facilitate binary diff uploads. Unfortunately, if you need to make minor changes to massive files and want to prevent re-upload of the whole file, you will need to use the Dropbox Desktop client.