similar to: mirroring a huge file using rsync while it's being written to.

Hello, let me describe my setup. Source server is debian wheezy, rsync 3.0.9 Destination is qnap TS-410, with rsyncd enabled, rsync 3.0.7 I'm trying to rsync two files, which are exported from source server as iscsi targets (windows iscsi backups). Files are on btrfs, so I use snapshots during rsync, so files don't change. One file is 50GB, second is 550GB in size. Initial sync over

https://bugzilla.samba.org/show_bug.cgi?id=8990 Summary: --append-verify doesn't spot file differences, even with --checksum Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org

We have a rsync'd filesystem which generally contains very large files that only grow. We've specifically used the --append option to handle these files - since otherwise rsync is effectively CPU bound the whole time. I'd always assumed that any files that were simply modified (without a change in length) would be handled under the existing rsync logic. However it appears that

Hello, I''d like to know if there has been any discussion about adding a new feature to write (add) data at an offset, but without overwriting existing data, or re-writing the existing data. Essentially, in-place addition/removal of data to a file at a place other than the end of the file. Some possible use-cases of such a feature would be: (a) Databases (currently hack around this by

Is there a way to force rsync to perform delta-transfers even on local drive-to-drive copies? The reason I ask is that I've started using a USB flash drive as a medium for "poor man's off-site backup". Rsync does a beautiful job on avoiding overwrites of unchanged files, but it would be even better if it only rewrote the portions of large files that had actually changed

is there a way to somehow force rsync to check checksum in blocks vs the whole file and xfer only part that has changed vs the whole file? for instance i have a few gig file, and it usually keeps adding at the end, maybe a line a day, yet rsync xfer the whole file over and it takes forever... -- http://alexus.org/

Hi, I have to sync two directories and one is an ftp mount. I had to set a different tmp dir as tmp files are not allowed in ftp mounts so I see no point in copying things to a temp dir if they won't be used for the transfer. Is there any way to eliminate the use of a tmp dir? If not, could it be a feature request? Regards,

'Lo. I've run into a frustrating issue when trying to synchronize a directory hierarchy over a reliable (but slow) connection to an unreliable remote. Basically, I have the following: http://mvn-repository.io7m.com/com/io7m/ This is a set of nested directories containing binaries and sources for projects I develop/maintain. Every time a new release is made, I deploy the binaries and

Is it safe to open the index to do searches on while another process is writing to the index? -- Posted via http://www.ruby-forum.com/.

Hi, how does rsync work if it compares two very huge files on two distinct hosts (rsync uses a networked connection, via SSH)? Some observation seems to indicate, that rsync first reads (and checksums?) the remote (destination) side, then, if finished, it reads (and checksums?) the local (source) side and then starts transferring the delta if done with the comparison of these two files on both

Hi, i have to tranfer large files each 5-100 GB (mo-fri) over dsl line. unfortunately dsl lines are often not very stable and i got a broken pipe error. (dsl lines are getting a new ip if they are broken or at least after a reconnect every 24 hours) i had a script which detect the rsync error and restart the transmission. this means that if a file has transfered e.g. 80 % i start again from

I am using rsync 2.6.9 in daemon mode under Cygwin, and having trouble reconciling its --append behavior with that described in the man page: The man page says that when you use --append, it will update a file by appending, which presumes the existing data on the receiving side matches. But when I run rsync with append mode when the existing file on the receiving side is shorter than on the

Hi all, >From the manpage of rsync, I can see the following descriptions: --inplace The option implies --partial (since an interrupted transfer does not delete the file) So I do the following testings on the `--inplace' and `--partial' for resuming a file with the following steps: 1- rsync ftp.cn.debian.org::debian/dists/wheezy/main/binary-amd64/

Hello list! How dangerous is acctually the --inplace option if you want to run rsync to update files that are only read and not written to? What is the worst that can happen? The file is not readable, the reader gets half the file of an old version and the rest is from the new version? There is not a simple way to make it update the file in the standard way and then change the ownership

https://bugzilla.samba.org/show_bug.cgi?id=13071 Bug ID: 13071 Summary: [PATCH] Allow --partial-dir with --inplace Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

There is the problem which I discribed here https://bugs.centos.org/view.php?id=12820. rsync does not break hard-link into destination if hard-link has be broken in source with option inplace. The problem remains in the latest version of rsync? -- View this message in context: http://samba.2283325.n4.nabble.com/There-is-problem-of-rsync-with-options-hard-links-inplace-tp4714872.html Sent from

Hi. This is bug report and simultaneously urgent asking for help. I am trying to write my rsync wrapper script, which will create minutely snapshots of my data using --link-dest. I want this script to be robust, it should work even if I do suspend/hibernate/reboot without notifying the script about this actions, it should work if I make hard-reset of the computer and if I disconnect network. Also

Hi, I am wondering how rsync-3.0.6 react if it encounters ESTALE error while synching? If I remember correctly then the rsync-2.6.0 skipping that file/dir in case of ESTALE error. Jignesh. -------------- next part -------------- HTML attachment scrubbed and removed

>- --inplace and --append-verify are essentially irrelevant when >- --link-dest is in play. With --link-dest in play the target system >must write an entirely new file even for a change in permissions or >timestamps so any potential benefit by these options are out the >window from the start. The only thing they can do is add the >possibility of incomplete or corrupt copies on

https://bugzilla.samba.org/show_bug.cgi?id=5201 Summary: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode Product: rsync Version: 3.0.0 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: