--password-file
The man page says: --password-file This option allows you to provide a password in a file for accessing an rsync daemon. The file must not be world readable. It should contain just the password as a single line. The trouble with this is that the file then shows up like this in an ls: 2 -rw--- 1 root wheel 9 Jan 24 2007 /var/ rsync.passwd.server.mount 2 -rw--- 1 root wheel 11 Jun 30 2007 /var/ rsync.passwd.serv2.moun2 2 -rw--- 1 root wheel 10 Jul 14 2008 /var/ rsync.passwd.tuesday.mountie This tells everyone the exact length of each password (8 characters, 10, characters, and 9 characters, respectively). Granted, it's not MUCH of a security issue, and I guess the password- files can be stored somewhere out of reach, but it seems to be that it would be better if the password-file supported a format something like this: ## Rsync Password File # # updated 20090117 server::mount password serv2::moun2password # This server is only used on tuesdays tue::mountiepassword ## EOF First off, it would let you have multiple passwords in a single file and second of all, it would completely conceal the lengths of each password. (or some other format, even htpasswd format) -- The Salvation Army Band played and the children drunk lemonade and the morning lasted all day, all day. And through an open window came like Sinatra in a younger day pushing the town away -- 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
patch to detect IPv6 on Cygwin
New Cygwin release 1.7 (which will be released in a few months) will contain IPv6 support, but rsync configure doesn't currently detect it. I'm using the following patch to enable the detection: --- origsrc/rsync-3.0.4/configure.in2008-09-06 18:32:26.0 +0200 +++ src/rsync-3.0.4/configure.in2009-02-15 20:38:41.532123700 +0100 @@ -198,8 +198,18 @@ [don't even try to use IPv6])) if test x$enable_ipv6 != xno; then AC_MSG_CHECKING([ipv6 stack type]) - for i in inria kame linux-glibc linux-inet6 toshiba v6d zeta; do + for i in cygwin inria kame linux-glibc linux-inet6 toshiba v6d zeta; do case $i in + cygwin) + AC_EGREP_CPP(yes, [ +#include netinet/in.h +#ifdef _CYGWIN_IN6_H +yes +#endif], + [ipv6type=$i; + AC_DEFINE(INET6, 1, [true if you have IPv6]) + ]) + ;; inria) # http://www.kame.net/ AC_EGREP_CPP(yes, [ -- Lapo Luchini - http://lapo.it/ -- 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 6116] New: Cannot access files in exposed shadow drive in version 3.0.5
https://bugzilla.samba.org/show_bug.cgi?id=6116 Summary: Cannot access files in exposed shadow drive in version 3.0.5 Product: rsync Version: 3.0.5 Platform: x86 OS/Version: Windows NT Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: way...@samba.org ReportedBy: le...@vaultnow.com QAContact: rsync...@samba.org Hi, In 3.0.4, I encountered a problem with dot-dir path (e.g. , foo/./bar) inside a -files-from file when the root of the transfer isn't in the current directory. This was fixed in 3.05 (well, partially). 3.0.5 bug fixes release info: - Fixed the use of a dot-dir path (e.g. foo/./bar) inside a --files-from file when the root of the transfer isn't the current directory. 3.05 works fine unless the backup is using an exposed shadow. In this case, the C: and D: drives are exposed as H: and I: respectively. I get the following error: rsync: change_dir /cygdrive/H failed: No such host or network path (136) This causes zero (0) files to be transferred, and rsync error: some files/attrs were not transferred (see previous (Repeats for I: drive) rsync: change_dir /cygdrive/I failed: No such host or network path (136) and rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1040) [sender=3.0.5] Cygwin is able to change_dir into /cygdrive/H and /cygdrive/I with no problems, so the drives appear to be valid. This DOES work in 2.6.8. Leon -- 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: Macintosh rsync: Inconsistent Behaviour: Hints Appreciated
Thank you, both for your advice and your patience! I had assumed that because the built-in version didn't care about EAs, not handling EAs wouldn't matter (i.e. that whatever it did transfer, it would recognise as being the same as the source). Clearly that isn't the case. Apologies for the delay reply - there were some problems with the build of rsync3 (I didn't have xcode installed on the relevant machine, so no make), but it's now working beautifully. On Thu, Feb 12, 2009 at 11:40 AM, Mike Bombich m...@bombich.com wrote: You're using the version of rsync that is built-in to Mac OS X. Don't do that. It's a fairly old version (though it is maintained by Apple), and it doesn't handle extended attribute modifications (or lack thereof), thus it transfers them every time. When you have many files with resource forks or other extended attributes, you'll see files getting copied every time regardless of whether they've been modified. rsync 3.0.x handles these much more efficiently. -- 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
