At 17:00 19.12.2016, wrote:

><snipp> But the filename twice can happen under other circumstances; if you've 
>seen this happen, it's almost certainly because the file changed during 
>transfer. Rsync does no locking. Which means that: if you are modifying a file 
>while it's being transferred, then probably the checksum will fail and it'll 
>go round again. And if it goes around twice, and it still fails, then it 
>prints a message saying; Error, checksum failed, file changed during transfer? 
>And it's probably a file like a log file that's being constantly updated and 
>so the checksums didn't match because it's never going to be able to get it 
>exact; it means that what you've got on the other end is something which will 
>approximate some snapshot of the file, but because it's not doing any locking, 
>it can't guarantee that it's got a particular snapshot of the file, because 
>you can't have an atomic read of the whole file. [31m, 49s] <snipp>
>nope, this is wrong, there is no message "checksum failed"

Actually rsync does that (from a log on our server):
WARNING: PUBLIC_SERVER_BACKUP/wiki/data/index/i10.idx failed verification -- 
update retained (will try again).

So it did recognize a change and synched it a second time. Don't know what 
if the file changes again though.

>to be a valuable backup solution, i`d like some networker a`like behaviour 
>which gives "file changed during save"
>i wonder what`s so difficult for rsync to "look" at the timestamp or checksum 
>a second time after transfer and if it changed it should spit out a warning....
>isn`t this something which _could_ be implemented, if somebody is able to do 
>ist ?

Maybe it's a question of informational flags (-v, --progress, --stats etc).

bye  Fabi

Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options:
Before posting, read:

Reply via email to