similar to: mixed case file systems.

I have attached a patch that supports a new "--direct-write" option. The result of using this option is to write directly to the destination files, instead of a temporary file first. The reason this patch is needed is for rsyncing to a device where the device is full or nearly full. Say that I am writing to a device that has 1 Meg free, and a 2 meg file on that device is out of date.

Updated to current cvs without the --exclude-from - patch. This patch allows specifying a --link-dest path similar to --compare-dest except that unchanged files are hard-linked to the --link-dest path instead of producing a sparse tree. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember

As discussed at: https://www.redhat.com/archives/libguestfs/2014-September/msg00215.html Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com> --- maint.mk | 7 ------- 1 file changed, 7 deletions(-) diff --git a/maint.mk b/maint.mk index b6ec1b5..76759d4 100644 --- a/maint.mk +++ b/maint.mk @@ -408,13 +408,6 @@ sc_error_message_uppercase: { echo '$(ME): found capitalized error

Does rsync work over an NFS mount? --Karl _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

I am trying to rsync a file of 10gb between an NT host running Cygwin 4.10 and a Solaris 8 host running rsync 2.5.1 but am having problems with what appears to be a 2gb file limit - the truncation point occurs at 2096111616 bytes. The target filesystem definately supports files over 2GB. Any ideas how to overcome this limitation? Regards, Craig Donnelly Andel Consulting 10 Fenchurch Avenue

What is the default block size? I have a few files 30+mb and data is just added to the end of them. It seems like it takes longer to sync them that it was to send it initially. Should I change the block size or something else? I am running: rsync -z -e ssh *.* user@linuxbox:data/ I need to use ssh because I am going over the internet and sending "company data". -------------- next

FYI, We've been using the 2.4.7pre1 release for several days now, with nary a hang problem. We haven't seen the EOF bug at all, which was what we upgraded for. This is with transfers of as much as 50GB to set up an initial mirror. The only thing we did was set timeout=0 -- which I guess is unnecessary. The semantics of this flag are a bit unclear. We thought was 'time since

Hello, Recently while working with rsync as the way to mirror large (several GB) archive on a regular basis, I came across several problems, and also got the ideas about their possible solutions - please could you investigate & consider implementing the features, described below, to future RSYNC releases ? - when the checksumming (consider very large archive, several GB) stage of rsync

I recently installed rsync 2.5.5 on both my rsync server and client being used. I installed the latest version because I was having problems with rsync stalling with version 2.4.6 (I read that 2.5.5 was supposed to clear this up or at least give more appropriate errors). I am still having problems with rsync stalling even after upgrading to 2.5.5. It only stalls in the "/home" tree

Hi. When I discovered rsync, it immediately became one of my most indispensable utilities. It's a real godsend on bandwidth-limited links, especially digital cellular. It works remarkably well in the general case, but I think the algorithm could be improved for one very important special case. Many (or even most) of the updated files I transfer with rsync change only by stuff being appending

> 3. The only evidence of any problem from the vampire command is the > events logged on the PDC, and the invalid passwords. I tried > deleting the trust account on the PDC and rejoining several times, > with Samba on, off, and nmbd on and off. The result is always the > same. The bad password hashes are always the same for each account. > If I change a password on the PDC

rsync -e 'ssh -x' --log-format="%o /%n %b" -tLr --delete --files-from=files-to-sync --exclude-from=files-to-exclude user@host:/ /temp/ del. /etc/mail/spamfilter/mx1/whitelist.conf 0 del. /etc/mail/spamfilter/mx1/blacklist.conf 0 recv /etc/mail/spamfilter/mx1/ 0 recv /etc/mail/spamfilter/mx1/blacklist.conf 211 recv /etc/mail/spamfilter/mx1/whitelist.conf 924 Why does rsync

cc -g -I. -I. -I/opt/openssl-0.9.6c/include -I. -I/usr/local/include -DETCDIR=\"/opt/openssh-3.0.2p1-x509/etc\" -D_PATH_SSH_PROGRAM=\"/opt/openssh-3.0.2p1-x509/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/openssh-3.0.2p1-x509/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/opt/openssh-3.0.2p1-x509/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\"

> -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@redhat.com] > Sent: Thursday, March 12, 2015 4:32 PM > To: Chen, Hanxiao/陈 晗霄 > Cc: libguestfs@redhat.com > Subject: Re: [Libguestfs] [PATCH] maint.mk: remove error_message_period check > > On Wed, Mar 11, 2015 at 01:18:45AM -0400, Chen Hanxiao wrote: > > As discussed at: > >

Hi, Does rsync lock the source files while its copying? Any input is appreciated. Thank you Dietrich

People of cygwin & rsync, I recently attempted to get cygwin and rsync working to solve a backup/mirroring need in my computer life. Well, as you might guess, I ran into a little but of trouble. Strangely enough, rsync seemed to be regularly hanging when I attempted to do a "get" (sycronize a remote to a local dir). Well, considering I want to automate this, that was not going

If I run the following command: # /usr/local/bin/rsync -a --stats -v --delete --force --recursive /source /dest building file list ... done source/file1 source/file2 source/file3 source/file4 source/file5 source/ Number of files: 74 Number of files transferred: 5 Total file size: 1104726340 bytes Total transferred file size: 115163136 bytes Literal data: 463500 bytes Matched data: 114699636

Is anyone else concerned about the fact that rsync doesn't guarantee to produce identical file copies on the the target machine? Don't get me wrong in sounding critical because I think that rsync is a great example of how software should be written. (I often make the observation, as I learn more about Linux, and inevitably find myself comparing open source applications to Microsoft

There's a rather old bug report in Debian's bug tracking system (see http://bugs.debian.org/27126) about wanting to be able to specify the maximum file size, as well as the minimum file size. Here's the text: Sometimes, it's useful to specify a file size range one is interested in. For example, I'd like to keep an up-to-date mirror of Debian, but I currently

The problem is caused because rsync does not close its sockets, and WinSock is a quite strict on this. The solution is to shutdown and close the fd. This is a 5-minute hack I've done to fix the obvious occurrences of the problem. It might be better to extend rsyncs cleanup functions for this, but here it is anyway to alert people to the problem and its fix. Max. BEGIN PATCH diff -mru