DO NOT REPLY [Bug 5008] New: make check fails on Cygwin (default-acls)
https://bugzilla.samba.org/show_bug.cgi?id=5008 Summary: make check fails on Cygwin (default-acls) Product: rsync Version: 3.0.0 Platform: x86 OS/Version: Other Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] On cygwin, using only the additional --wish-rsh=rsh parameter to ./configure, make check passes all the tests (some are skipped) except for default-acls. This is a copy of test.log: -- Testing for symlinks using 'test -h' sending incremental file list created directory /tmp/local/unixutil/.tmp/rsync/rsync-3.0.0pre1/testtmp/default-acls/da777/to delta-transmission disabled for local transfer or --whole-file file program dir/ total: matches=0 hash_hits=0 false_alarms=0 data=16 sent 168 bytes received 53 bytes 147.33 bytes/sec total size is 16 speedup is 0.07 permissions: rwx-- on /tmp/local/unixutil/.tmp/rsync/rsync-3.0.0pre1/testtmp/default-acls/da777/to should be: rwxrwxrwx failed test Target da777 -- The complete build is OK under Solaris 2.8. -- 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: Problem with hard links
On 9/28/07, Matt McCutchen [EMAIL PROTECTED] wrote: Fabian's suggestion to use the CVS rsync with incremental recursion is good; that will be an improvement. However, rsync still has to remember all files in S1 that had multiple hard links in case they show up again in S2. If remembering the contents of even one of the directories makes rsync run out of memory, you'll have to do something different. Thanks for your reply.I think that there is too many files in S1 ... Not in the general case, but if the hard links are between corresponding files (e.g., S1/path/to/X and S2/path/to/X; often the case in incremental backups), you can simply use --link-dest on the second run, like this: rsync options P/S1/ remote:P/S1/ rsync options --link-dest=../S1/ P/S2/ remote:P/S2/ I'm using rsync to generate a copy of a list of backups generated by backuppc, and unfortunately the structure of S1 and S2 are absolutely not the same ... -- 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 stops/hangs (from windows to debian)
I'm not using rsync through ssh since this is on an internal network. Would pipes still be used? The only difference I can tell between my situation and Alain's is that my case the windows client is sending files instead of receiving. Are there any suggestions for a work-around other than switch all the computers to *nix (which I'm in the process of doing anyway)? I'm hoping for a more immediate solution... -Miles Raymond Matt McCutchen wrote: On 10/4/07, Wayne Davison [EMAIL PROTECTED] wrote: Yes, due to a bug in cygwin's pipe code (the pipe that carries data between rsync and ssh). Until cygwin fixes its pipe code, you can only reliably rsync data to/from a cygwin system if you avoid pipes (e.g. use a daemon transfer). I'm not sure the problem is limited to pipes. Alain Deseine reported a hang when a Cygwin client accessed a daemon: http://lists.samba.org/archive/rsync/2007-August/018393.html 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
Re: rsync stops/hangs (from windows to debian)
At 01:26 05.10.2007 -0700, Miles Raymond wrote: I'm not using rsync through ssh since this is on an internal network. Would pipes still be used? The only difference I can tell between my situation and Alain's is that my case the windows client is sending files instead of receiving. Are there any suggestions for a work-around other than switch all the computers to *nix (which I'm in the process of doing anyway)? I'm hoping for a more immediate solution... You can try to build (or find) a cygwin version of the new 3.0.0 or the cvs version. I also had stalls using the Linux 2.6.9 that were solved using the newer rsync (so no cygwin involved). I don't know if a simple bugfix was responsible for this or the new protocol 30. In the latter case you need to have the new rsync on both ends or they use an earlier protocol. bye Fabi -- 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: (no subject)
On Thu 04 Oct 2007, Frank Thomas wrote: 1. rsync recognizes that Directory1 is not on server1, but it's inode still is. Rsync reads the new directory name and flags the name change from Directory1 to DirectoryNew on server1. The problem here is that rsync is stateless; i.e. it can't recognize that the inode is still there, because it has no idea the inode was ever there. To accommodate that, a major redesign would probably be needed. Paul Slootman -- 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.0.0pre1 released
On Thu 04 Oct 2007, Wayne Davison wrote: I've just released rsync 3.0.0pre1, the first pre-release version for the upcoming 3.0.0 release. The version number is getting such a large I've prepared a Debian package, version 3.0.0~pre1-1. It's been uploaded to the experimental distribution. Once versions have been built for the different architectures it should be available through http://packages.debian.org/search?keywords=rsyncsearchon=namesexact=1 Paul Slootman -- 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: Problem with hard links
On 10/5/07, limule pika [EMAIL PROTECTED] wrote: On 9/28/07, Matt McCutchen [EMAIL PROTECTED] wrote: [...] If remembering the contents of even one of the directories makes rsync run out of memory, you'll have to do something different. Thanks for your reply.I think that there is too many files in S1 ... I'm using rsync to generate a copy of a list of backups generated by backuppc, and unfortunately the structure of S1 and S2 are absolutely not the same ... Then, unfortunately, there is no good way to preserve the hard links without adding more memory to the system. 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
Re: Rsync not able to transfer over jumbo frames?
On 10/5/07, Jake Conk [EMAIL PROTECTED] wrote: I think whatever your reading is probably wrong. It doesn't make sense or else like wha you said nothing will be able to communicate over jumbo frames. *Jumbo* frames are fine. In one place in your original message, you made a typo and called them *jumble* frames, and I'm making a joke about that; it was too funny to pass up. 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
Re: Rsync 3.0.0pre1 released
On 10/4/07, Manuel Kissoyan [EMAIL PROTECTED] wrote: Wondering if there are somewhere to download an rpm version for centos? My RPM will probably work fine on CentOS, as it is based on the Fedora packaging and Fedora is similar to CentOS. If you want a pure CentOS package, you or I could rebuild the SRPM at http://mirror.centos.org/centos/5.0/os/SRPMS/rsync-2.6.8-3.1.src.rpm . 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
RE: Rsync 3.0.0pre1 released
Can I compile this for cygwin or has someone already done so? _ Stephen Zemlicka Integrated Computer Technologies PH. 608-558-5926 E-Mail [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt McCutchen Sent: Thursday, October 04, 2007 11:05 PM To: rsync@lists.samba.org Subject: Re: Rsync 3.0.0pre1 released On 10/4/07, Wayne Davison [EMAIL PROTECTED] wrote: I've just released rsync 3.0.0pre1, the first pre-release version for the upcoming 3.0.0 release. Hooray! I have built an RPM of rsync 3.0.0pre1 and posted it here: http://mattmccutchen.net/rsync/#rsync-packages This pre-release has finally given me the impetus to install and start using rsync 3.0.0* for everyday tasks, so I hope I will catch any bugs. Wayne, regarding the link on http://rsync.samba.org/download.html : I plan to continue to provide RPMs of release and pre-release versions of rsync, but of course they won't be RPMs patched with ACL support any more. Also, it would be nice if you updated the link to point to the URL above because the old URL will stop working sometime next year. 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 -- 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.0.0pre1 released
Cwrsync 2.0.10.3001 packages are available for testing. Regards Tev Download link: http://downloads.sourceforge.net/sereds/cwRsync_2.0.10.3001_Installer.zip http://downloads.sourceforge.net/sereds/cwRsync_Server_2.0.10.3001_Installer .zip == cwRsync VERSION 2.0.10.3001 - October 2007 highlights (see changelog for more info) - Rsync 3.0.0 pre1 - cygwin 1.5.24-1 - OpenSSH 4.7p1 - OpenSSL 0.9.8d Signatures: MD5: f8ae4aafdaf72794e7a0105d972b897a *cwRsync_2.0.10.3001_Installer.zip 72730c50dc08e7c8bcab5d7a69e5850b *cwRsync_Server_2.0.10.3001_Installer.zip SHA1: 0929b8601e6d3df37725466484e5ca699389653a *cwRsync_2.0.10.3001_Installer.zip 01738c63d22f702833bacb64048c1f9d6cdcd3b6 *cwRsync_Server_2.0.10.3001_Installer.zip === -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Davison Sent: Friday, October 05, 2007 3:15 AM To: [EMAIL PROTECTED] Cc: rsync@lists.samba.org Subject: Rsync 3.0.0pre1 released I've just released rsync 3.0.0pre1, the first pre-release version for the upcoming 3.0.0 release. The version number is getting such a large bump due to the addition of an incremental recursion scan (which helps a lot with large transfers) and the official arrival of several other new features, including ACL support, extended attribute support, file- name character-set conversion, etc. Please test this out and email the rsync mailing list with any questions, comments, bug reports, etc. Thanks! You can download the tar file and its signature from here: http://rsync.samba.org/ftp/rsync/rsync-3.0.0pre1.tar.gz http://rsync.samba.org/ftp/rsync/rsync-3.0.0pre1.tar.gz.asc To see a summary of the changes since 2.6.9, visit this link: http://rsync.samba.org/ftp/rsync/rsync-3.0.0pre1-NEWS ..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
Re: (no subject)
Frank Thomas, on 10/4/2007 3:57 PM, said the following: it would be nice to have rsync to be intelligent enough to recognize a name change but not an inode change on the source. Seems to me the best way to accomplish this is to be sure that the parent directory is not a directory that someone can rename... ie, when I rsync our home directories, there is no danger of anyone ever renaming the 'home' directory... So, just put the top level directories that *can* be renamed by the users into a parent directory that they can *not* rename, and use that for the root for your rsync... Or maybe I'm missing something? -- Best regards, Charles -- 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: [Detecting renames]
On Thu, Oct 04, 2007 at 01:57:22PM -0600, Frank Thomas wrote: This action is the simplest method of performing an rsync, but it would be nice to have rsync to be intelligent enough to recognize a name change but not an inode change on the source. For the next feature release of rsync after 3.0.0, I'm imagining adding support for a database API that would allow extra information about files to be maintained and used (completely optional, of course). In the scenario that you described, this new rsync would be run using a DB cache and the --checksum option, which would lookup files on the sending side by their inode + size + mtime + ctime (making the checksum lookup efficient). The receiving side would lookup incoming files based on its checksum + size + mtime + ctime in order to find a local file that it could use for hard-linking, copying, and/or renaming. In the meantime, the only rsync solution is the detect-renamed patch that Matt mentioned. ..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
version 3 and glibc
wondering if the only option to have rsync 3 running is have a glibc 2.4+? I have a backup server and many other servers running cpanel on them so a glibc update is not an option as it could skrew up the systems. Any idea or workaround? Or i should to stick with old versions of rsync? Thanx in advance! Manuel -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Renaming a directory results in an expensive retransmission
We are using rsync for several years, but since a couple of months we use it to backup remote servers, some with more than 200GB capacity. Especially Windows users sometimes have the (bad) habit to change the name of a directory with huge amounts of data below them. We see the same nasty results as you are talking about: * rsync thinks that the old directory name has disappeared, and deletes the directory on the target machine, throwing away the expensive transmission * the new directory name initiates a fresh / full (re)transmission, sometimes taking days while the real work would be done in minutes... * the servers we backup have between 20GB and 200GB capacity. * all rsync's are run in parallel, average sync time is 1.5 hour for 900GB. * when a user behaves as described, it takes days to a week to resync. It is a tricky problem to deal with i think, it is tempting to keep a checksum'd file/directory list on both sides with information like: * a fingerprint/signature/checksum to identify each file or directory * inode number * timestamp * filesize In case a files appears to be deleted, because the name/path is changed, it could possibly be identified by it's fingerprint and used to sync cleverly ;-) This in the thought of expanding --fuzzy, giving it more functionality (hint). For some time i am experimenting with a solution to this problem, by some sort of a preprocessor, that tries to identify in the described way, creating hardlinks (ln) to let rsync think the files are already in the new location. I am traversing on both sides (remote and local) the directory trees, producing a file with the information described above, but it is still work in progress... The cost of keeping a database in this scenario would be truly justified for me. That rsync deletes the files in the old location is then no problem for me anymore. But i am just a user with needs... looking for a solution to a problem also, hoping this can be solved by the clever developers ;-) Maybe there is already a solution available, and we are chasing shadows ? Thanks, Nico Frank Thomas schreef: Good day, I’ve got a question regarding the usage of rsync that I just cannot figure out. I’ve done a fare hunt for the answer, but I’m stumped. Here is the situation. I have two pc’s running linux and using rsync to perform a backup from server1 to server2. For example: rsync -avzr -e 'ssh -i/root/.ssh/id_rsa' --delete /home/samba/admin/software www.some-server.com:/home/RemoteSystems/company/home/samba/admin Let’s say I have a directory within rsync’s scope to sync called directory1. Rsync is run and directory1 is sync’ed from server1 to server2. Also, a file named File1 is sync’ed because it is in the directory being sync’ed. Server1 server2 Directory1 Directory1 File1File1 Now, let’s say a user comes and changes the name of the Directory1 on server1 to DirectoryNew, rsync performs the following actions: 1. rsync recognizes that Directory 1 is not on server1, but it is on server2, so it flags it and it’s contents for deletion on server2. 2. rsync recognizes that DirectoryNew is on server1, but not on server2, so it flags it and it’s contents for copying to server2. 3. rsync performs these actions to make the two directories the same. This action is the simplest method of performing an rsync, but it would be nice to have rsync to be intelligent enough to recognize a name change but not an inode change on the source. So the action performed would be, 1. rsync recognizes that Directory1 is not on server1, but it’s inode still is. Rsync reads the new directory name and flags the name change from Directory1 to DirectoryNew on server1. 2. Rsync reads server2 and sees that Directory1 exists, and flags a pending name change on server2 from Directory1 to DirectoryNew. 3. Name is changed on server2. No files or directories are deleted and re-transferred from source to destination as the structure under the directory has not changed. Why go through all this work? I’ve had personnel change a directory name that has several gigabytes of data in it without notifying me and at night, rsync tries to perform the directory and file dance and fails simply because the volume is so great. It would be nice to either, one, recognize a large discrepancy between the source and destination before anything occurs, by giving a message of amount of potential bytes that would be transferred, (this doesn’t work with dry-run option), or do the fancy dance by recognizing a name change over a deletion of a directory. Thanks. *Frank Thomas* -- Behandeld door / Handled by: N.J. van der
Re: ACL's on Mac OS X
Ah, but then the million dollar question: if this new version supports OS X ACLs, does it also support OS X resource forks? Thanks, noam Noam Birnbaum http://maccentricsolutions.com/ 877.luv.macs x89 Apple Certified Technical Coordinator Apple Certified Help Desk Specialist On Oct 4, 2007, at 4:10 PM, Wayne Davison wrote: On Thu, Oct 04, 2007 at 02:08:42PM -0700, Noam Birnbaum wrote: Running Mac OS X 10.4.10. In my testing I have not found a way to rsync ACLs from source to destination. Is there a solution out there? Try the latest CVS source -- it now supports OS X ACLs. If you want to backup to a non-OS X system, see the --fake-super option (which would need to affect the non-OS X side) as this allows the ACL data to be stashed in an rsync-specific extended attribute. ..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
Re: ACL's on Mac OS X
On Fri, Oct 05, 2007 at 04:22:22PM -0700, Noam Birnbaum wrote: Ah, but then the million dollar question: if this new version supports OS X ACLs, does it also support OS X resource forks? Resource forks on OS X have been supported for a while now -- they are handled via the --xattrs option by rsync (and handled more efficiently than the rsync that comes with OS X, since 3.x does not re-send unchanged xattr data). If you'd like to use the OS X-specific -E option instead of using -A and -X, you can create a popt alias by adding this to your ~/.popt file: rsync alias -E -AX ..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
CVS update: rsync
Date: Fri Oct 5 20:40:36 2007 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv1467 Modified Files: rsync.h Log Message: Make sure ICONV_OPTION is unset if we didn't find iconv_open() and iconv.h. Revisions: rsync.h 1.368 = 1.369 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.h?r1=1.368r2=1.369 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/lib
Date: Fri Oct 5 20:47:18 2007 Author: wayned Update of /data/cvs/rsync/lib In directory dp.samba.org:/tmp/cvs-serv4569/lib Modified Files: sysacls.c Log Message: A couple tweaks to the AIX ACL code. Revisions: sysacls.c 1.10 = 1.11 http://www.samba.org/cgi-bin/cvsweb/rsync/lib/sysacls.c?r1=1.10r2=1.11 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
