rights messed up after moving installation

[lee]

Reindl Harald <h.reindl at thelounge.net> writes:

> Am 06.11.2012 19:26, schrieb lee:
>>> rsync never will transmit unchanged data again because it wroks
>>> like diff -
>> 
>> Are you sure?
>
> 100% sure
>
> this below is the vnstat-output of my main backup-machine
> every night there are synced 1.5 TB data with the rsync.sh
> from my last post
>
> with rsync you can even transmit iso-images of a linux
> installation-DVD and update RC1 to RC2 without much traffic
>
> oversimplyfied:
> * on both sides a rsync-process is running
> * both are making a checksum of the same data-area
> * let's say 250 blocks
> * only this cheksum is transmitted and decides transmit data itself
> * attributes are also listed on both sides and compared

I thought it works like this, which involves reading all the files on
both sides.  For the purpose of copying files from one place to another
on the same machine, I'm wondering if it might be more efficient to go
by file modification times and file size --- if they are sufficiently
reliable --- and to just copy over the files that have changed.  It
could save some reading for creating the checksums --- but then, once
the files have been read, they are in the cache anyway.

> finally i did recursive chown/chgrp/chmod with find on a server with
> around 700k files, with progress/verbose rsync is listing them all,
> the changes are applied on the receiver but the amount of transmitted
> data goes to zero - without measure it you see the speed over WAN
>
> thats why rsync over ssh with --compress is my most loved tool
>
>      11/04/12      1.60 GiB |  263.07 MiB |    1.86 GiB |  180.50 kbit/s
>      11/05/12      1.37 GiB |  409.26 MiB |    1.77 GiB |  171.48 kbit/s
>      11/06/12      3.88 GiB |  466.12 MiB |    4.34 GiB |  445.64 kbit/s

It might be nice to have something like an rsync-FS, analogous to ftpfs
:)