Notices

Well, that's up to the implementation of rsync on the platform.

As far as I know (and now checking from wikipedia confirms this) the linux rsync divides all files into fixed size blocks and only transmits the differing blocks based on checksumming algorithm. (source: http://en.wikipedia.org/wiki/Rsync, see the section "Determining which parts of a file have changed")

A short test of my own; I transferred a binary file of about 9MB with cloudsync.sh, then hexedited it so that I changed just one byte somewhere about middle of the file, and resent it.

From this simple test you can see that on the second serving, only 15kB needed to be sent to transfer the changes to the file. (and most of this is transferring the MD5 hashes of the file blocks I guess, plus the changed block when it is detected...)

The "speedup is 273.79" means that the filesize/(sent_bytes+received_bytes) = 273.79, so only 2.7% of the total file size needed to be sent on the second round.

First of all, thanks for the script. After using it for some time I wanted to have easy access to the log, as well as a way of knowing when a sync is done. This is how I do it:

1) Redirect all output/logging to a log file (.txt extension)
2) After removing the lock file, open the txt-file via xdg-open (launches the document viewer)

Would this still work? I'm thinking about dropping the owncloud cli-tool and use this. Since currently owncloud is holding me back from using newer vers of nextcloud on the desktop.

x

Yes, as cloudsync uses basic shell tools it works pretty much on anything you could want to try it on.

Okay I might need your assistance once I get around to trying this. Since I'm hoping to have it sync in both ways. which I know you didn't want for your use.

Would be amazing if I could get this going reliably. Since I then can still sync my caldav & cardiac with the newer nextcloud and then all is well again.

x