Re: Almost desperate on rsync from macbook to NAS
2009/10/31 Matt McCutchen m...@mattmccutchen.net: On Sat, 2009-10-31 at 17:06 +0100, Boniforti Flavio wrote: I'm almost getting exhausted, thus I have to bother you people to get some help. That's a non sequitur. Check http://www.catb.org/~esr/faqs/smart-questions.html#id382403 . Yep, sorry... I really just wanted to shout it out... [cut] What is the nature of the failure? Files ending up in the wrong place, or rsync not seeing the old files and wanting to retransfer everything, or not connecting to the rsync daemon at all, or what?? Well, actually in my last attempt, files are getting deleted (I used the -n switch to not waste my actually transferred data) on the destination path... I tried to play around with trailing slashes, but I got tired while not succeeding :-/ Putting a trailing slash on the source should have worked. (Whether there is one on the destination shouldn't matter.) OK, I'll retry with trailing path on source and if it doesn't matter whether or not there's also one in the destination path, I'll leave it as it is (*with* trailing slash)... Get back to you soon, as I get some more trials done. Thanks so far, F. -- Please use reply-all for most replies to avoid omitting the mailing list. 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 2790] Add support for converting filenames into different encodings
https://bugzilla.samba.org/show_bug.cgi?id=2790 way...@samba.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from way...@samba.org 2009-11-01 16:17 CST --- You're right, this bug should be closed, so I'm doing so now. The idea of doing an rsync version that does all the conversions on one side so that it can work with an older, non-iconv rsync is not something that I plan to implement. Note that it would require that the converting side cache both versions of the names (because it needs to be able to sort by the remote names, and access files via the local names), and thus bloat the amount of required memory for the transfer. -- 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. -- Please use reply-all for most replies to avoid omitting the mailing list. 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: OS X 10.6 (Snow Leopard) HFS+ File Compression
Mike, thanks for the patch. Will this patch be maintained in rsync- patches-3.0.6.tar.gz ? On Oct 28, 2009, at 1:20 AM, Mike Bombich wrote: HFS compression can be preserved as long as the relevant xattr(s) and flags on those files are preserved. A compressed file has the compressed data in a hidden xattr (com.apple.decmpfs if 4Kb, com.apple.ResourceFork if more), and has the UF_COMPRESSED flag set (decimal 40). When rsync encounters a file like this, it should ignore the data fork of the file, which will appear to contain normal, uncompressed data. It should also pass a special flag to the xattr calls to expose the decmpfs xattrs. I've already implemented this in rsync (3.0.6), I just hadn't taken the time to craft the HFS-compression-specific changes into a patch. I did that this evening and attached it below. These are changes against the 3.0.6 base, plus the crtimes, fileflags, and backup-dir-dels patches. It should work, at minimum, against the 3.0.6 base plus the fileflags patch (that patch is required). Let me know if it doesn't work for you, it's entirely possible that I overlooked something in the extraction. Mike rsync_3.0.6-hfs-compression_20091027.diff On Oct 27, 2009, at 11:08 PM, Matt McCutchen wrote: On Tue, 2009-10-27 at 23:38 -0400, Tony wrote: When rsync 3.0.6 copies files with HFS+ File Compression, the new extended attribute decmpfs is not preserved, and the UF_COMPRESSED flag is not set on the destination and the destination file is not compressed. I examined the destination file as described in ars technica (with ls and xattr from a 10.5 Leopard boot), and the compressed data is moved from the resource fork to the data fork, and the extended attributes '@' are removed from the file. As far as I know, only ditto in 10.6 can handle HFS+ File Compression. (I even tested a 'clone' with disk utility (file copy, not block), and it also failed (block copy, of course works). Rsync is just reading and writing files via the filesystem API; it has no access to any of the flags or xattrs used to implement the compression. I guess the filesystem doesn't compress new files by default. If it had an API to request compression, rsync could use that API when writing the destination files. Unfortunately, the API ditto is using appears to be private to Apple. See the post from brkirch beginning The first thing that I tried to do on this page: http://www.macosxhints.com/article.php?story=20090902223042255 So anyone interested in making rsync compress the destination files would probably have to copy the relevant code from afsctool. This could be shared as a patch; I feel quite sure it would not be adopted in the main version of rsync. -- Matt -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[SCM] The rsync repository. branch, master, updated. v3.0.3-260-gef9d3a1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project The rsync repository.. The branch, master has been updated via ef9d3a152b5438bb961d3a150634e5811147b3c1 (commit) from fe16d9a67db9aeaa424bd35976eefa2a11861a3b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit ef9d3a152b5438bb961d3a150634e5811147b3c1 Author: Wayne Davison way...@samba.org Date: Sun Nov 1 13:26:15 2009 -0800 Make sure rwrite() can handle any logcode value in --msgs2stderr mode. --- Summary of changes: log.c |4 1 files changed, 4 insertions(+), 0 deletions(-) hooks/post-receive -- The rsync repository. ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
[SCM] The rsync repository. branch, master, updated. v3.0.3-262-g84c11e8
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project The rsync repository.. The branch, master has been updated via 84c11e85a4c4a12ecacba24afe9617222e4361e6 (commit) via 6be8a8b14ddf566b56a1c8252e5be40edc44de2e (commit) from ef9d3a152b5438bb961d3a150634e5811147b3c1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 84c11e85a4c4a12ecacba24afe9617222e4361e6 Author: Wayne Davison way...@samba.org Date: Sun Nov 1 13:57:17 2009 -0800 Fix MSG_IO_TIMEOUT when the daemon is the receiver. commit 6be8a8b14ddf566b56a1c8252e5be40edc44de2e Author: Wayne Davison way...@samba.org Date: Sun Nov 1 13:36:02 2009 -0800 A daemon treats --msgs2stderr as output only to the log, not the user. --- Summary of changes: io.c |2 +- log.c | 14 ++ 2 files changed, 11 insertions(+), 5 deletions(-) hooks/post-receive -- The rsync repository. ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
