similar to: [PATCH] Exceeding white spaces and a typo

Rsync-2.5.2 does not gracefully report connection and transfer errors and always properly return with a non-zero exit code, despite many assurances to the contrary in the code and commit logs. It seems a kludge to handle a special case of lost connections to older servers was FAR too aggressive! With '-vvv' I also print the source of the exit_cleanup() call, and optionally with

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've compiled rsync 3.0.3 on OSX 10.4 PPC via the plain jane ./configure; make method (no patches). The resulting binary has then been moved to /usr/local/bin/rsync3 and copied to a OSX 10.5.4 Intel client machine as rsync3. I then run the following command: rsync3 -vvv -e ssh -avAX --progress --delete -

for those who care, the yodl pkg, a prereq for building rsync3-cvs docs (& more?), had 'issues' @ version <= v2.04 with building cleanly on osx. it's been updated today to v2.10, http://sourceforge.net/project/showfiles.php?group_id=126615 v2.10 builds clealy, without req'd patching or error, and works just fine when/as used by rsync3 -- or elsewhere.

Hi Ram, In OS X, some font types (not all) put the font payload in the resource fork. Netatalk provides AFP filesharing, imitating the resource forks by creating secondary files in ?.Appledouble? folders within each folder. Netatalk tracks the resource forks, and other metadata, by keeping a ?Desktop database? at the root of the shared volume ? look for .AppleDesktop, and .AppleDB. You can

Hello, Noticed this (bug?) while testing out rsync. For a little background, I need to push files real-time to some front-end servers, and I am thinking of switching from some custom shell scripts that do this job to rsync. I am thinking of running rsync as a daemon on the front-end servers, and doing an upload from the back-end server to push the data out as it comes in. So, here is the deal:

Dear Martin Pool. We regularly use rsync for making backups of our file systems but we have noticed that the atimes are not transferred with the files and are also always updated on the sender's side. Therefore, we have created a modified version of rsync based on rsync-2.6.6 protocol version 29 which transfers the access times with the transferred files and also allows to preserve the access

Did anyone ever get rsync3 to compile as a universal binary and work correctly on both tiger and leopard on ppc and intel? David.

I create a new thread, because the issue is not really the same, but i copy here the thread that made me jump into the list. My issue is not really that it waits before starting copying, but a general performance issue, specially when there are multiple rsync running at the same time. Here is my situation : I have multiple clients (around 20) with users and i want to rsync their home dirs with

Ok, so i did some tests. find /path -type f -ls > /dev/null First on my local SSD disk (1.9 millions files) : 1 find : real 2m16.743s user 0m7.607s sys 0m45.952s 10 concurrent finds (approx same results for each) : real 4m48.629s user 0m11.013s sys 2m0.288s Almost double time is somehow logic. Now same test on my server on the iSCSI disk (when there is no other activity) (2.8 millions

Hi Bryan, thanks for your kind reply but it happend only with some fonts not all font file, (email with attachment is under verification by admin, so i resend this without attachment file) here i attach 2 screenshot one original folder and second backup folder, you can notice that the font .otf, .ttf, .dfont have no problem in rsync it copied as it is but the font that not show extension (Font

https://bugzilla.samba.org/show_bug.cgi?id=6276 Summary: crtimes.patch does not preserve creation dates on Mac x86_64 only Product: rsync Version: 3.0.6 Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

hi, as it's been awhile since my last attempts w/ v269, i'm building the latest rsync3-svs on osx 10.4.8; looking to see what's evolved re: acls & xattrs support on osx ... @ build, i note complaint abt a missing yodl2man, which originates with YODL. YODL, then requires icmake. as neither is available on osx, it's src build time. on building debian's icmake (already

Typically rsync exits and reports an error such as: rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) rsync: write failed on "/Volumes/Backup/big_file.dmg": No space left on device (28) rsync: connection unexpectedly closed (67174 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /src/ rsync-3.0.5/io.c(600)

https://bugzilla.samba.org/show_bug.cgi?id=10181 Summary: --stats bug Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: RutleCorps at gmail.com QAContact: rsync-qa at

https://bugzilla.samba.org/show_bug.cgi?id=12472 Bug ID: 12472 Summary: invalid rsync-command syntax or options with —stats Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: core Assignee: wayned at samba.org

Hello, since we are using rsync for backing up millions of files in a virtual environment, and most of the virtual machines run on SSD cached storage, i`d be curious how that negatively impacts lifetime of the SSD`s when we do rsync run every night for backup my question: does rsync normal file comparison run to determine if anything has changed change atime of any files ? for me it seems,

https://bugzilla.samba.org/show_bug.cgi?id=5309 Summary: double free or corruption while using rsync 3.0.0 stable Product: rsync Version: 3.0.0 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy:

what is the source and destination filesystem? here is some report that rsync has some problem with HFS+ filesystems and "ressource forks": http://quesera.com/reynhout/misc/rsync+hfsmode/ but as you are using ubuntu and not osx i`m curious what`s the problem, so i think we need more information here. regards roland > Gesendet: Freitag, 12. Dezember 2014 um 15:31 Uhr > Von:

An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20141214/3d32f770/attachment.html>

Hello, We have run and stopped by chance command "fsck -y" on one of our raid disks (with ext3 file system). After that we have found that SOME files disappeared (they are not seen in the directories where they have been before). The data are extremely important and contain a lot of programs, scripts for some data analysis and very hard to recover by hands. I have run ''fsck