DO NOT REPLY [Bug 5221] New: rsync error: partial transfer (code 23) at main.c(576)
https://bugzilla.samba.org/show_bug.cgi?id=5221 Summary: rsync error: partial transfer (code 23) at main.c(576) Product: rsync Version: 2.6.3 Platform: Sparc OS/Version: SunOS Status: NEW Severity: major Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] we get rsync error: partial transfer (code 23) at main.c(576) please let us know the resolution for the same or this can be ignorable -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsync 3's -E and -X
So, It might be a little late to rock this boat, but I just was turned on to rsync 3. So, Apple's changes to rsync to support metadata has -E as: -E --extended-attributes copy extended attributes, resource forks This was done in OS X 10.4, in April of 2005. It looks like rsync 3 though is moving -E to -X, and changing what -E does: -X, --xattrs preserve extended attributes -E, --executability preserve executability Was there any thought of switching what these two flags do in rsync 3? If not, this will break compatibility with scripts on OS X for people who install rsync 3 themselves. - Josh -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5223] New: Options to limit --one-file-system at the source or destination.
https://bugzilla.samba.org/show_bug.cgi?id=5223 Summary: Options to limit --one-file-system at the source or destination. Product: rsync Version: 3.0.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] Currently, the --one-file-system applies to both the source and destination and this is a problem. In my source, I have a symlink pointing to a directory on another device which I would like to have copied. I thus use --copy-unsafe-links. I also use --delete. This is dangerous because if there is a bug in my script, I would not like the destination to become suddenly / and deletion occurs on mounted network drives (granted, the machine would be toast, but the damage would be limited to the machine; not the corporate network). If I make use of --one-file-system, the symlink at the source gets ignored. So I need a --one-file-system option that applies only to the destination, probably named something like --one-file-system-at-destination. Could that be easily implemented? The following two options would be nice: --one-file-system-at-source # Limit to one file system at the source. --one-file-system-at-destination # Limit to one file system at the destination. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync 3's -E and -X
On Tue, Jan 22, 2008 at 12:23:16PM +, Josh Durham wrote: > It looks like rsync 3 though is moving -E to -X, and changing what -E does: Rsync has used the -X option for xattr data in the patches since the beginning. The xattrs.diff first appeared in the patches dir in mid 2005, but existed prior to that (it was created by Red Hat). Rsync's -E option has been released in 3 releases already, so that's not going to change either. You can, however, feel free to use popt aliases to map -E to -X, -AX, or whatever you like if you'd like to continue to use -E. See my prior emails on the subject for the details. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Thought on large files
Hi There, I've been toying around with the code of rsync on and off for a while, and I had a thought that I would like some comments on. Its to do with very large files and disk space. One of the common uses of rsync is to use it as a backup program. A client connects to the rsync server, and sends over any changed files. If the client has very large files that have changed marginally, then rsync efficiently only sends the changed bits. On the server side, one may have it set up to create 'snapshots' of the existing data there by hardlinking that data to another directory periodically. Theres plenty of documentation on the web how to do this so I won't go into it further. This is very effective and uses quite little disk space since a file that does not change effectively doesn't take up any more disk space (not much more anyway), even if it exists now in many snapshots. One place where this falls down is if the file is very large. Lets say the file, whatever it is, is a 10Gb file, and that some small amount of data changes in it. This is efficiently sent accross by rsync, BUT the rsync server side will correctly break the hard-link and create a new file with the changed bits. This means, if even 1 byte of that 10Gb file changes, you now have to store that whole file again. I won't get into the whole issue of why one would have big files etc... I see it all the time, especially in the Microsoft world, with Outlook PST files, and Microsoft Exchange Database files. What my thoughts were is that if the server could transparently break a large file into chunks and store them that way, then one can still make use of hard-links efficiently. For example, going back to a 10Gb Exchange Database file, its likely not going to change too much during use. So if the server stored the huge clumsy 'priv1.edb' as: .priv1.edb._somemagicstring_.1 .priv1.edb._somemagicstring_.2 etc... and intelligently only broke the 'hard-links' of the bits that actually change, then it all works well. One could have an option to enable this for files bigger than a certain size, and break them into specific sized chunks. One could quite rightly argue that this changes rsync from a tool that synchronizes data between places to a dedicated backup tool (as the two sides will now have physically different data), however I could see it being useful, especially since it wouldn't need changes on the client side as the server still presents it as just one file. What are your comments? Good idea? Stupid idea? Been done before? Does anyone have some hints about where in the code I should look to make these changes so I can test it out? Brendan Grieve -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Thought on large files
On Wed, 2008-01-23 at 13:38 +0900, Brendan Grieve wrote: > Lets say > the file, whatever it is, is a 10Gb file, and that some small amount of > data changes in it. This is efficiently sent accross by rsync, BUT the > rsync server side will correctly break the hard-link and create a new > file with the changed bits. This means, if even 1 byte of that 10Gb file > changes, you now have to store that whole file again. > What my thoughts were is that if the server could transparently break a > large file into chunks and store them that way, then one can still make > use of hard-links efficiently. This is a fine idea, but I don't think support for this should be added to rsync. Instead, I suggest that you use rdiff-backup ( http://www.nongnu.org/rdiff-backup/ ), a backup tool that stores an ordinary latest snapshot of the source along with reverse deltas for previous snapshots and redundant attribute information both in its own format. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5220] PATCH SUBMITTED: New Feature: stdio model for client
https://bugzilla.samba.org/show_bug.cgi?id=5220 --- Comment #2 from [EMAIL PROTECTED] 2008-01-23 00:55 CST --- You can make rsync effectively use an existing fd by passing an $RSYNC_CONNECT_PROG that refers to a program that shuttles data between its stdin/stdout and the desired fd. I'm not sure that it is worth adding the & syntax to the official rsync. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5221] rsync error: partial transfer (code 23) at main.c(576)
https://bugzilla.samba.org/show_bug.cgi?id=5221 --- Comment #1 from [EMAIL PROTECTED] 2008-01-23 01:03 CST --- Rsync prints the "code 23" message at the end of the run when at least one non-fatal error occurred that may have affected the correctness of the run. Rsync should have printed another message to stderr stating the specific problem; what was that message? BTW, consider upgrading to a modern version of rsync. The latest stable version is 2.6.9. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
