similar to: Non-standard usage of rsync

Hi, on my linux box (2.4.21-pre4-ac4) I've used rsync to mirror a rather large /usr/local tree (4 Gb) After transmission of many files I get the error message rsync error: some files could not be transferred (code 23) at main.c(1045) According to /usr/include/asm/errno.h the code 23 says File table overflow What can I do about that? Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer

I just took a look at the 2.5.5 codebase to see how easy it would be to write a little driver script that downloads a big directory tree from an rsync daemon the chunky way (get a list of a module's subdirectories and do the transfer by subdirectory). The reason for doing this is obvious when you have large directory trees, as is the case for many of us. Unfortunately the way list_only is

A while back, I asked if there had been any consideration in making rsync support direct ssl (as opposed to just ssh). I've been looking around for a secure way (e.g. encrypted, so passwords are never in the clear, and even content is obscured from sniffers) to allow a set of limited-trust users (limited-trust being defined as mostly customers, whom you trust with their own data, but not with

Can someone explain to me what is happening here: ~ $ touch foo ~ $ ln foo bar ~ $ ls foo bar bar foo ~ $ mv foo bar ~ $ ls foo bar bar foo I try to move a file over a hard linked copy of itself and the move fails, but there is no error. Is this the intended behavior? -- Ben Escoto

Hi, this might be offtopic - please excuse if it turns out to be. I have rather big ( > 20 Gb) source archives on two different machines. Unfortunately there is only a very slow network connection between these machines. To synchronize these two archives (directory trees), I'd like to generate a directory tree of signature files (instead of the real ones). Then I would copy only these to

Hi, I've rebuilt rsync (which was running just fine for quite some time) and it works if used via ssh or if the daemon is started via ssh. But it crashed in daemon mode (started standalone or by xinetd) Here is the gdb log gdb ... set follow-fork-mode child run --daemon --no-detach Program received signal SIGSEGV, Segmentation fault. [Switching to process 32521] 0x08056577 in glob_expand

I, too, was disappointed with rsync's performance when no changes were required (23 minutes to verify that a system of about 3200 files was identical). I wrote a little client/server python app which does the verification, and then hands rsync the list of files to update. This reduced the optimal case compare time to under 30 seconds. Here's what it does, and forgive me if these sound

Dear all, I've been trying to track down a problem with timeouts when pulling data from an rsync daemon and I have now run out of any useful ideas. The problem manifests itself when I try to transfer a large directory tree on a slow client machine. What happens then is that the client rsync process successfully receives the list of files from the server, then begins checking the local

Hi, I have two problems with rsync 1st) if I give both commandline options -u and -c it looks as if a file which is more recent but different on the destination is not updated, i.e. -u overrules -c Is that true? 2nd) There is a symlink A on <SourceDir> which refers to a directory On the other hand, A is the name of a subdirectory of <DestDir> Now doing

Is there a good place to get information about the list of all possible output and error messages rsync generates? Or should I just muck around the source code (which I haven't looked at yet) and find them? I am doing something where I would like to parse rsync's output using Perl into a set of data structures. I already have something that works under normal conditions. Eventually

I was at first, but then removed it. The results were still insufficiently fast. > Were you using the -c option of rsync? It sounds like you > were and it's > extremely slow. I knew somebody who once went to > extraordinary lengths to > avoid the overhead of -c, making a big patch to rsync to > cache checksums, > when all he had to do was not use -c.

Hello! As I was found rsync do not detect file renaming. If I just copy my backup.0.tgz (many Mbytes in size having it's md5) to backup.1.tgz (which will be equial in size and md5) it will be the same file in fact... Rsync will delete old file (backup.0.tgz) on the receiving side and download new one (backup.1.tgz). I do not think there are any difficulties to detect this situation and

Chris, to put things in the right prespective, you should read (if you haven't done so already) the original paper describing the design behind batch mode. The design and implementation of this functionality goes back to a project called the Internet2 Distributed Storage Infrastructure (I2-DSI). As part of that project, the authors created a modified version of rsync (called rsync+)

I've just started using rsync, and it's way cool. I checked the FAQ, the broken mailing list archive search function, and scanned the archives, but didn't see this mentioned. I presume it's a fairly common need: I'm mirroring files automatically and daily from one site to another, and anticipate the day when the size of the files may exceed the size of the destination disk.

I must run Turbo C for the university. The install seemed to go alright, but when I try to run it I get: $ wine TC.EXE Warning: unprotecting memory to allow real-mode calls. NULL pointer accesses will no longer be caught. err:module:MZ_DoLoadImage insufficient DOS memory winevdm: can't exec 'C:\tc\BIN\TC.EXE': error=8 What should I do? I've 512 MB RAM- I can't imagine

There is a new patch named "delete-during.diff" in the CVS "patches" dir. This patch adds the ability for rsync to incrementally delete files in each directory during the normal course of the transfer rather than doing a separate delete scan either before or after the transfer. The patch renames the current --delete option into --delete-before and makes --delete behave in the

I have downloaded and built rsync 2.6.0 on our HP ProLiant DL380-G3 servers (2 Hyperthread processors, 4 GB RAM, 840 GB Hard Disk, etc. etc.) running Red Hat 8 with the latest errata kernel (2.4.20-28smp) and updates from HP for RH8. rsync is run in daemon mode from xinetd. When doing transfers the machine requesting the transfer starts to run out of memory. After every rsync transfer there

At the moment, if you start an rsyncd that's not running as root using default settings it will have some trouble. rsyncd tries to use chroot by default, but this will always fail if it's not started by root. It does emit an error message in this case, but I wonder if some people find this a bit confusing until they discover the setting. I have in the past. It might be better that if

Rsync list: Alberto and I have done a couple more exchanges by private email, and we found that he wasn't turning on my include/exclude optimization in his test because he had an "exclude" directive in rsyncd.conf. He has now removed that and run the test again. His very interesting results are below with my comments. Note that his case is rather pathological because he's got

I am puzzled as to why I can't get the option --link-dest to work properly. When I use this option when both source and destinations are on a local filesystem the hard-linking of the target against the link-dest directory does work, but when the source is a remote directory (via ssh or rsync server) hard links are not created. I suspect it has something to do with setting the correct