Is there a way of getting rsync to just list what it would do without doing anything? Failing that is there any other way to get a list of changes between two trees of files where one of them is remote?

Does the --dry-run option + suitable 'how to determine what is different' options not give you what you want? I assume from what you wrote below that the video files are going to be either added or deleted and not changed, so you can probably just compare dates and presence. James

I've got an archive of 30G+ of video files that needs to be synchronised occasionally with a system that has limited quota. I want to get a list of new/changed files that I can pass as parameters to tar and then take a tar file on a USB stick with the new files.

I know I could run "find ." on both sides and then compare the output files, but I'd prefer something less hacky if possible.

-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main

Russell Coker <russell@coker.com.au> writes:

Is there a way of getting rsync to just list what it would do without doing anything? Failing that is there any other way to get a list of changes between two trees of files where one of them is remote?

I've got an archive of 30G+ of video files that needs to be synchronised occasionally with a system that has limited quota.

I assume this means you have a limited *network* quota, i.e. you cannot simply run rsync, because even a --dry-run -i would transfer significant data. I had such a situation when trying to update a mirror of Debian's repo, to a site that had only 33kbps. The way I solved this was to keep TWO copies of the repo locally -- one that was as at the last sync, and one as at today. Then, do an rsync --only-write-batch between them -- this is a local rsync -- and post the resulting file to the site on a CD. Then, sshing over the 33kbps line, I would run rsync --read-batch to apply the patch on the far end (from the CD). This worked out quite well, but assumes that only one side has changes. Otherwise, it doesn't work and you're screwed. Also, this was at at Ubuntu 8.04 and it had an exciting feature where if you use UUIDs in fstab, and you reboot with an LVM snapshot still present, it will prefer the snapshot over the origin. Meaning that for months (until the snapshot ran out of space) I was accidentally editing the snapshot instead of the origin. That was "interesting times"...