Vitorio Machado
2008-Jan-24 12:26 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Somebody knows if it's possible to compile rsync (version 3 would be great, but can be 2.6.x) under Mac OS X 10.3.9 with extended attributes? Under OS 10.3.9 the Apple shipped rsync have not yet the -E argument option. RsyncX have a double free bug that is annoying. "Q" rsync 2.6.6 with extended attributes binary only works on 10.4 and above. I have tried to compile rsync from source but the problem I found is that the xattr patch seems to need the acl patch. But 10.3 doesn't have the ACL support so doesn't provides the expected headers and the make command fails. I will try out 2 more things: 1) Ignore the instructions of xattr patch and do not apply the acl patch before xattr (but if those instructions are there, I'm almost sure it's for a good reason...) 2) Try to get a patched rsync via fink or darwinport But I would appreciate any help or feedback about compiling a extended- attribute rsync on 10.3.9, even more if it's the last version (meaning that rsync could still progress on those macs and the development is not closed for them). Best regards, Vitorio Machado -------------- next part -------------- HTML attachment scrubbed and removed
Vitorio Machado
2008-Jan-24 13:28 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Sorry about spamming the list. This update is just to say that I have tested solutions 1 and 2 and there is no solution: 1) If I configure with --disable-acl --enable-xattr, configure is OK but make can't compile xattr.c because it seems linked to ACL code... 2) The versions disponible at darwinport and fink are unpatched (without extended-attributes) or just avaliable for 10.4+. So I would really need to compile it from source, if someone have a magic argument like --compile-on-10.3-with-xattr-without-acl... Best regards, Vitorio Machado Le 24 janv. 08 ? 13:25, Vitorio Machado a ?crit :> Somebody knows if it's possible to compile rsync (version 3 would be > great, but can be 2.6.x) under Mac OS X 10.3.9 with extended > attributes? > > Under OS 10.3.9 the Apple shipped rsync have not yet the -E argument > option. RsyncX have a double free bug that is annoying. "Q" rsync > 2.6.6 with extended attributes binary only works on 10.4 and above. > > I have tried to compile rsync from source but the problem I found is > that the xattr patch seems to need the acl patch. But 10.3 doesn't > have the ACL support so doesn't provides the expected headers and > the make command fails. > > I will try out 2 more things: > 1) Ignore the instructions of xattr patch and do not apply the acl > patch before xattr (but if those instructions are there, I'm almost > sure it's for a good reason...) > 2) Try to get a patched rsync via fink or darwinport > > But I would appreciate any help or feedback about compiling a > extended-attribute rsync on 10.3.9, even more if it's the last > version (meaning that rsync could still progress on those macs and > the development is not closed for them). > > Best regards, > > Vitorio Machado-------------- next part -------------- HTML attachment scrubbed and removed
Matt McCutchen
2008-Jan-24 15:31 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
On Thu, 2008-01-24 at 13:25 +0100, Vitorio Machado wrote:> Somebody knows if it's possible to compile rsync (version 3 would be > great, but can be 2.6.x) under Mac OS X 10.3.9 with extended > attributes?> I have tried to compile rsync from source but the problem I found is > that the xattr patch seems to need the acl patch. But 10.3 doesn't > have the ACL support so doesn't provides the expected headers and the > make command fails.In rsync 3, support for preserving acls and xattrs is in the trunk and the "acls" and "xattrs" patches just add acl and xattr protocol compatibility with older versions of rsync. Thus, you probably don't need to apply either patch. Try compiling rsync 3.0.0pre8 without patches, and if you still run into problems, post the exact error message(s). ?Matt
Vitorio Machado
2008-Jan-26 14:43 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Sorry, I've misread your mail. But don't give up, I think that if we correct the headers in 10.3, we have a chance to make it compile. We should look at the ACL and xattr code and see if there are only constant and variable definition on the system headers that are not found in 10.3 or if it's more deep lied to the 10.4 API. In this case it represents much more work, but we have the chance that the basic system layer (Darwin) of 10.4 is released open source... So maybe we could take some code from there to have our xattr on 10.3... So, if nobody have a better idea, I think we should proceed like this: 1) Look on ACL and xattr code to understand what code they expect from the system 2a) If it's just a definition stuff (variable declaration, constants, etc) we can try a workaround of the configure script or something to put another header for 10.3 systems giving all those stuff that aren't built-in in the system headers. This shouldn't represent a lot of work 2b) If xattr and ACL code expect to use system fonctions, it won't be so simple... We can try patching the 10.3 system with some code of Darwin 8 (system code of 10.4 OS) hoping not have to go too deep, but just getting 1 or 2 files from it. 3) compile rsync with xattr support successfully with our little hacking. I will start looking into the code to try to figure out xattr and acl dependencies on the system. But I don't have Mac OS 10.3 here, only 10.4. It will be impossible for me to make any test today. Chin up, we can do it! Vitorio Le 26 janv. 08 ? 13:47, Robert DuToit a ?crit :> Hi Vitorio, > > Well, actually, it only compiles only with --disable-acl-support -- > disable-xattr-support. which kind of defeats the whole purpose > since xattrs are out of the picture. > > > Rob > > > > On Jan 26, 2008, at 7:24 AM, Vitorio Machado wrote: > >> Interesting, >> >> So patched rsync compiles with --disable-acl-support --enable- >> xattr-support. >> Can you give an output of rsync --version to see if it says that >> xattr is enabled on capabilities? >> >> Best regards, >> >> Vitorio >> >> Le 26 janv. 08 ? 12:36, Robert DuToit a ?crit : >> >>> Hi Matt, >>> >>> I tried >>> >>> ./configure --disable-acl-support --enable-xattr-support >>> >>> and got >>> >>> `XATTR_NOFOLLOW' undeclared (first use in this function) >>> >>> so then >>> >>> /configure --disable-acl-support --disable-xattr-support >>> >>> which worked >>> >>> then added patches >>> >>> patch -p1 <patches/flags.diff >>> patch -p1 <patches/osx-create-time.diff >>> ./configure --disable-acl-support --enable-xattr-support >>> make >>> >>> OK this time. Then I tried some simple tests on OS10.3X >>> >>> mypathto/rsync -a --fileflags testdir destdir (no AX of course!) >>> >>> It works and flags seem to work at least for locked files. >>> Creation time was not saved though..... >>> >>> any thoughts on xattrs or creation dates? Quite a few people >>> still ask me to make support scripts on OS 10.3.9. Acls probably >>> not such an issue on OS 10.3 and earlier. >>> >>> Thanks Rob >>> >> >
Vitorio Machado
2008-Jan-26 19:22 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Well, it seems that we just use definitions from the system acl.h So putting the acl.h attached into /Developer/SDKs/MacOSX10.3.9.sdk/ usr/include/sys/ should correct first errors. I'm still studying the code to see if it needs other changes. -------------- next part -------------- A non-text attachment was scrubbed... Name: acl.h Type: application/octet-stream Size: 6630 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20080126/53ec1ba3/acl.obj -------------- next part -------------- Le 26 janv. 08 ? 19:44, Robert DuToit a ?crit :> Hi Vitorio, > This is a bit out of my league. I've done some applescript > applications including backuplist+ which rsync 3 has improved a > great deal. I was hoping to make it backwards compatible to 10.3X > so it would be great if we can do something to improve the xattrs > and or ACL's. If you saw my other post, I also found that OSX > creation dates aren't saved either with the build I did on 10.3 > even with the patch for that.... > > I have little experience with OBJ-C (though I use lots of "call > method") or C etc.... so you would have to see if you can figure > that out. Keep me informed. Anything I can do though , let me know. > Thanks, Rob > > > On Jan 26, 2008, at 9:38 AM, Vitorio Machado wrote: > >> Sorry, I've misread your mail. >> >> But don't give up, I think that if we correct the headers in 10.3, >> we have a chance to make it compile. We should look at the ACL and >> xattr code and see if there are only constant and variable >> definition on the system headers that are not found in 10.3 or if >> it's more deep lied to the 10.4 API. In this case it represents >> much more work, but we have the chance that the basic system layer >> (Darwin) of 10.4 is released open source... So maybe we could take >> some code from there to have our xattr on 10.3... >> >> So, if nobody have a better idea, I think we should proceed like >> this: >> >> 1) Look on ACL and xattr code to understand what code they expect >> from the system >> >> 2a) If it's just a definition stuff (variable declaration, >> constants, etc) we can try a workaround of the configure script or >> something to put another header for 10.3 systems giving all those >> stuff that aren't built-in in the system headers. This shouldn't >> represent a lot of work >> >> 2b) If xattr and ACL code expect to use system fonctions, it won't >> be so simple... We can try patching the 10.3 system with some code >> of Darwin 8 (system code of 10.4 OS) hoping not have to go too >> deep, but just getting 1 or 2 files from it. >> >> 3) compile rsync with xattr support successfully with our little >> hacking. >> >> I will start looking into the code to try to figure out xattr and >> acl dependencies on the system. But I don't have Mac OS 10.3 here, >> only 10.4. It will be impossible for me to make any test today. >> >> Chin up, we can do it! >> >> Vitorio >> >> Le 26 janv. 08 ? 13:47, Robert DuToit a ?crit : >> >>> Hi Vitorio, >>> >>> Well, actually, it only compiles only with --disable-acl-support >>> --disable-xattr-support. which kind of defeats the whole purpose >>> since xattrs are out of the picture. >>> >>> >>> Rob >>> >>> >>> >>> On Jan 26, 2008, at 7:24 AM, Vitorio Machado wrote: >>> >>>> Interesting, >>>> >>>> So patched rsync compiles with --disable-acl-support --enable- >>>> xattr-support. >>>> Can you give an output of rsync --version to see if it says that >>>> xattr is enabled on capabilities? >>>> >>>> Best regards, >>>> >>>> Vitorio >>>> >>>> Le 26 janv. 08 ? 12:36, Robert DuToit a ?crit : >>>> >>>>> Hi Matt, >>>>> >>>>> I tried >>>>> >>>>> ./configure --disable-acl-support --enable-xattr-support >>>>> >>>>> and got >>>>> >>>>> `XATTR_NOFOLLOW' undeclared (first use in this function) >>>>> >>>>> so then >>>>> >>>>> /configure --disable-acl-support --disable-xattr-support >>>>> >>>>> which worked >>>>> >>>>> then added patches >>>>> >>>>> patch -p1 <patches/flags.diff >>>>> patch -p1 <patches/osx-create-time.diff >>>>> ./configure --disable-acl-support --enable-xattr-support >>>>> make >>>>> >>>>> OK this time. Then I tried some simple tests on OS10.3X >>>>> >>>>> mypathto/rsync -a --fileflags testdir destdir (no AX of course!) >>>>> >>>>> It works and flags seem to work at least for locked files. >>>>> Creation time was not saved though..... >>>>> >>>>> any thoughts on xattrs or creation dates? Quite a few people >>>>> still ask me to make support scripts on OS 10.3.9. Acls >>>>> probably not such an issue on OS 10.3 and earlier. >>>>> >>>>> Thanks Rob >>>>> >>>> >>> >> >> -- >> To unsubscribe or change options: https://lists.samba.org/mailman/ >> listinfo/rsync >> Before posting, read: http://www.catb.org/~esr/faqs/smart- >> questions.html >
Vitorio Machado
2008-Jan-27 12:10 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
I've looked at the source of rsync-2.5.5.hfs and unfortunately it isn't patched the same way. If you are curious about it, just look at the syscall.c in rsync-2.5.5, in particular code between #ifdef DARWIN and #endif /* DARWIN */ I can't understand very well the code, but it seems to copy the ressources fork with system calls to cp command. So I think the best way of patching is doing what Matt said (using getattrlist instead of getxattr in 10.3). For the way of recognizing the OS (pseudo-coded as mac < 10.4), ./ configure gives target as powerpc-apple-darwin7.9.0 for 10.3.9, powerpc-apple-darwin8.11.0 for 10.4.11. darwinA.B.C represents Mac OS X 10.(A-4).B, so I think here is our way to create a flag like mac_bellow_tiger. But I don't know how to put this flag in the configure script, especially because it seems to be automatically generated, so would be better to patch the source than the result. Do someone knows how to do that? So my documentation phase is ended, I will concentrate my efforts now on coding something following Matt's example. Best regards, Vitorio
Vitorio
2008-Feb-16 11:27 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Some answers for your questions: 1)> rsync: ACLs are not supported on this client > rsync error: syntax or usage error (code 1) at main.c(1454) > [client=3.0.0pre9]no, you can't use -A (--acls) option with this version of rsync, as you compiled it without. And it's impossible to compile it with ACL support in 10.3. As 10.3 and 10.4 doesn't use ACL, this shouldn't be a major issue. You should only be aware to do not transfer files from a 10.5 computer by a 10.3 one (like 2 systems on the same machine, or shared folders over the network), as it would loose ACLs. 2)> you have this in configure: > > checking whether to support ACLs... running tests: > checking for acl_get_file in -lacl... no > checking for ACL support... no > checking ACL test results... No ACL support found > > I just have: > > checking whether to support ACLs... no > > but maybe because on this one I disabled ACL's in configure...Exactly. If you force --disable-acl-support it won't do some tests as you explicitly said to it to disable ACL. But the result is exactly the same. 3)> then I ran the same test with your patched rsync in leopard using > the same options (no A): > > Verifying: basic-permissions ... ok > Verifying: timestamps ... > Sub-test: modification time ... ok > ok > Verifying: symlinks ... FAIL > Verifying: symlink-ownership ... FAIL > Verifying: hardlinks ... ok > Verifying: resource-forks ... ok > Verifying: finder-flags ... FAIL > Verifying: finder-locks ... ok > Verifying: creation-date ... ok > Verifying: bsd-flags ... ok > Verifying: extended-attrs ... > Sub-test: on files ... FAIL > Sub-test: on directories ... FAIL > Sub-test: on symlinks ... FAIL > FAIL > Verifying: access-control-lists ... > Sub-test: on files ... FAIL > Sub-test: on dirs ... FAIL > FAIL > Verifying: fifo ... ok > Verifying: devices ... ok > Verifying: combo-tests ... > Sub-test: xattrs + rsrc forks ... FAIL > Sub-test: lots of metadata ... FAIL > FAIL > > it looks like rsync is not using the original patches for flags etc > but using yours instead perhaps? Is it supposed to override your > patch if the system is greater than 10.3.9? Or maybe because it was > compiled on 10.3.2? > > at any rate, huge progress. Thanks so much. I await any further > developments. Rob > > > ps the bouncer results without your patch and compiled on leopard: > > Verifying: basic-permissions ... ok > Verifying: timestamps ... > Sub-test: modification time ... ok > ok > Verifying: symlinks ... ok > Verifying: symlink-ownership ... ok > Verifying: hardlinks ... ok > Verifying: resource-forks ... ok > Verifying: finder-flags ... ok > Verifying: finder-locks ... ok > Verifying: creation-date ... ok > Verifying: bsd-flags ... ok > Verifying: extended-attrs ... > Sub-test: on files ... ok > Sub-test: on directories ... ok > Sub-test: on symlinks ... ok > ok > Verifying: access-control-lists ... > Sub-test: on files ... ok > Sub-test: on dirs ... ok > ok > Verifying: fifo ... FAIL > Verifying: devices ... FAIL > Verifying: combo-tests ... > Sub-test: xattrs + rsrc forks ... ok > Sub-test: lots of metadata ... ok > okThis behaviour is completely normal. The rsync functions are decided at the compilation time (maybe we should change some options to the execution time later, if it's possible?). So the patched rsync compiled on 10.3 won't use ACLs and probably other functions, even if you use the program on 10.4 or 10.5. All functionalities are decided at the compilation time by the configure script. In another hand, the patched rsync with 10.3 extended attributes support should compile as the unpatched one in 10.4 or 10.5 and present the same functionalities. This may be useless for people that don't use 10.3, but can be useful to have only one source code for all the systems and just recompile if needed. 4)> I did notice that applescript files didn't show up in the finder > but they were there if I ran ls command on the copy folder.Could you give me more details about those files? Do they have only resource fork or also data fork? A simple way to verify: ls -la /the/path/to/the/folder/having/the/problematic/file than ls -la /the/path/to/the/folder/having/the/problematic/file/rsrc Example on a text clipping (that is pure resource fork): iLaG:~/Desktop/rsync-3.0.0pre9 lag$ ls -la /Users/lag/Desktop/I\ dragged\ a\ text\ clipping\ in.textClipping -rw-r--r-- 1 lag lag 0 Jan 21 20:48 /Users/lag/Desktop/I dragged a text clipping in.textClipping iLaG:~/Desktop/rsync-3.0.0pre9 lag$ ls -la /Users/lag/Desktop/I\ dragged\ a\ text\ clipping\ in.textClipping/rsrc -rw-r--r-- 1 lag lag 3951 Jan 21 20:48 /Users/lag/Desktop/I dragged a text clipping in.textClipping/rsrc You can see that the normal file (the data fork) have a 0 size and the resource fork (/rsrc) have 3951 bytes. If I copy this file with the current (v0.2) version of the patched rsync it will disappear from the Finder. As it will be ok from the Terminal, if I try to copy it with the 10.4 cp (that is resource fork aware) it will not copy the resource fork and corrupt the destination file. So there is a problem there. I think that we are maybe missing a command after FSWriteFork to link the writed fork to the file. But I'm still investigating. If you have mixed data fork/resource fork files (as Classic programs) it would be interesting to see if they are well copied by the patched rsync, and if you can copy the destination file with /Developer/Tools/ CpMac in 10.3 or simply cp in 10.4 and see if the resource fork is always there or if we have corrupted it. I didn't test yet this behavior, will do it as soon as possible, but more people testing goes faster to discover and fix bugs. So if you have some time to spend on it, go ahead ;) Vitorio
Vitorio
2008-Feb-16 14:10 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Hmmm, so the problem seem to appear on all files who have resource fork, both files with or without data fork. Following those constats I would say that more generally, this version makes all resource fork files disappear from Finder... So, DON'T USE IT FOR BACKUP by now, only for development test. A working stable version will be available soon... Thanks for this test Rob, it proves that it's a general issue, and not only for 0-size data fork. Vitorio Le 16 f?vr. 08 ? 14:29, Robert DuToit a ?crit :> Hi Vitorio, > I did test with missing mailtest.scpt file > > dialup-4:~ astrid$ ls -la /volumes/Space/Users/robertdutoit/Desktop/ > rrr/xxx/mailtest.scpt > -rw-r--r--@ 1 astrid staff 10150 Dec 16 10:34 /volumes/Space/ > Users/robertdutoit/Desktop/rrr/xxx/mailtest.scpt > > dialup-4:~ astrid$ ls -la /volumes/Space/Users/robertdutoit/Desktop/ > rrr/xxx/mailtest.scpt/rsrc > -rw-r--r-- 1 astrid staff 356 Dec 16 10:34 /volumes/Space/Users/ > robertdutoit/Desktop/rrr/xxx/mailtest.scpt/rsrc > > That,s what I get. It is there but not visible in finder. Rob >
Vitorio Machado
2008-Feb-18 12:57 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
Hello Rob (and who else may be interested in news about 10.3 support patch), 1) Make sure you have a fresh copy of rsync (3.0.0pre9 for the moment) when patching and compiling. Patching an already patched source code won't do anything good. 2) If you removes the X option is the same as using normla rsync. It won't copy any extended attr. 3) I don't know exactly what you mean by no luck, but I tested the backup bouncer. It ends up in a 23 error code meaning all files haven't been copied. The good news: I've identified the problem. My patch is trying to follow symlinks when it shouldn't. This is a minor issue, the rsync should work nice to backup disks without aliases. For the aliases, it will take resource fork from the original file. Annoying, but not a big problem. The bad one: The simple way to say it to no follow symlinks appeared on 10.4 API... I've already tried some things, but it will be a little bit complicated to fix it. Well, problem identified, v0.4 will be released as soon as possible to fix it. I would say before the weekend. Thanks for testing and submitting bug reports. Vitorio PS: About backup bouncer test:> > Verifying: basic-permissions ... ok > Verifying: timestamps ... > Sub-test: modification time ... ok > ok > Verifying: symlinks ... ok > Verifying: symlink-ownership ... ok > Verifying: hardlinks ... FAIL > Verifying: resource-forks ... FAIL > Verifying: finder-flags ... FAIL > Verifying: finder-locks ... ok > Verifying: creation-date ... ok > Verifying: bsd-flags ... ok > Verifying: extended-attrs ... > Sub-test: on files ... okDon't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info> Sub-test: on directories ... FAILDon't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info> > Sub-test: on symlinks ... FAILDon't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info> > FAIL > Verifying: access-control-lists ... > Sub-test: on files ... okDon't expect this to work as 10.3 does not handle ACLs> > Sub-test: on dirs ... okDon't expect this to work as 10.3 does not handle ACLs> > ok > Verifying: fifo ... ok > Verifying: devices ... ok > Verifying: combo-tests ... > Sub-test: xattrs + rsrc forks ... FAILDon't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info> > Sub-test: lots of metadata ... FAILDon't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info> > FAIL >
Vitorio Machado
2008-Feb-22 08:27 UTC
Making rsync compile under Mac OS X 10.3.9 with extended attributes
@Rob:
Yes, rsync needs a newer version of autoconf than the one installed.
But you can download and compile it without problem:
1) get the sources from
http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.gz
2) unpack the sources
3) Open a Terminal and run the command:
cd <drop the autoconf source folder here>
4) run the command:
./configure && make && sudo make install
This combo makes everything you need and puts the autoconf in the right
place /usr/local
5) You need to say your system to use the newer autoconf by default.
- To do it once (the config will be active on the Terminal windows the
command was entered until the window is closed, run the command:
export PATH=/usr/local/bin:$PATH
- To do this automatically for all Terminal windows opened (what I
recommend), run the command:
echo "export PATH=/usr/local/bin:$PATH" >>.profile
Note that this won't do any changes in the current Terminal window. You
have to close and reopen it or to apply both first and second method to
have the right PATH.
6) You can verify the PATH running this command:
iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ echo $PATH
/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin
Don't worry if your PATH isn't exactly the same, what's important
for
autoconf is only that it begin with /usr/local/bin:
Anyways, I've put the binarie compiled on 10.3.9 PPC G3 that should
work also on lower systems here
http://shared.and.free.fr/rsync%203.0.0pre10%20patched%20v0.4.zip
@Matt: No, it makes an empty directory Src but refuses to list attrs of
anything on it claiming that one element of the path is not a folder...
What's true. Maybe I should be more flexible with alias in the name?
iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ sudo ./rsync -aHXN
--fileflags /Volumes/Src /Volumes/Dst/80-rsync-test/
Password:
rsync: get_xattr_names: llistxattr("Src/.DS_Store",1024) failed: Not a
directory (20)
rsync: get_xattr_names: llistxattr("Src/.Trashes",1024) failed: Not a
directory (20)
rsync: get_xattr_names: llistxattr("Src/00-basic-permissions",1024)
failed: Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/05-timestamps",1024) failed:
Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/10-symlinks",1024) failed: Not
a directory (20)
rsync: get_xattr_names: llistxattr("Src/15-symlink-ownership",1024)
failed: Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/20-hardlinks",1024) failed:
Not
a directory (20)
rsync: get_xattr_names: llistxattr("Src/30-resource-forks",1024)
failed: Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/40-finder-flags",1024) failed:
Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/45-finder-locks",1024) failed:
Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/50-creation-date",1024)
failed:
Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/60-bsd-flags",1024) failed:
Not
a directory (20)
rsync: get_xattr_names: llistxattr("Src/70-extended-attrs",1024)
failed: Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/80-access-control-lists",1024)
failed: Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/90-fifo",1024) failed: Not a
directory (20)
rsync: get_xattr_names: llistxattr("Src/95-devices",1024) failed: Not
a
directory (20)
rsync: get_xattr_names: llistxattr("Src/99-combo-tests",1024) failed:
Not a directory (20)
rsync: get_xattr_names: llistxattr("Src/bbouncer-vol",1024) failed:
Not
a directory (20)
rsync: get_xattr_names: llistxattr("Src/Desktop DB",1024) failed: Not
a
directory (20)
rsync: get_xattr_names: llistxattr("Src/Desktop DF",1024) failed: Not
a
directory (20)
rsync error: some files could not be transferred (code 23) at
main.c(1060) [sender=3.0.0pre10]
iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$
@Wayne: Thanks for the correction! I've another small warning:
clientname.c line 268
rprintf(FLOG, "%s: too short sockaddr_in6; length=%d\n",
fn, ai->ai_addrlen);
Length is a %d (int) but ai->ai_addrlen is a ssize_t (long int).
In many CPUs int and long int are both 32 bits so this is not a big
deal, but putting %ld instead of %d makes gcc happy :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4214 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20080222/ae770cc9/attachment.bin