rsync 2.6.9 on OS X. files with xattrs don't retain mtime.

2006-11-10 Thread Matt Jenns

I'm really excited about the recent work on extended attributes. I've
compiled 2.6.9 with xattr support, and run a few tests. It seems that
if I have a file with an extended attribute ( a resource fork in this
case), and I run rsync -aX , the mtime is not preserved.  Example:

stat xattrsrc/a
234881026 2894399 -rw--- 1 admin staff 0 1048576 "Nov 10 10:03:01
2006" "Nov 10 10:01:45 2006" "Nov 10 10:01:45 2006" 4096 2056 0
xattrsrc/a

./rsync -ax xattrsrc/a xattrdest/

stat xattrdest/a
234881026 2894405 -rw--- 1 admin staff 0 1048576 "Nov 10 10:03:01
2006" "Nov 10 10:01:45 2006" "Nov 10 10:03:01 2006" 4096 2048 0
xattrdest/a

note the preserved mtime, but stripped resource fork. Now with -X:

./rsync -axX xattrsrc/a xattrdest/

stat xattrdest/a
234881026 2894405 -rw--- 1 admin staff 0 1048576 "Nov 10 10:03:01
2006" "Nov 10 10:12:23 2006" "Nov 10 10:12:23 2006" 4096 2056 0
xattrdest/a

Is this the expected behaviour?

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


Internal error: wrong write used in receiver.

2006-11-10 Thread Sven Strickroth

Hi,

I'm using 2.6.9 but I get:

recv_files phase=1
generate_files phase=2
recv_files phase=2
recv_files finished
generate_files phase=3
deleting in home
delete_in_dir(home)
[generator] make_file(home/administ,*,2)
Internal error: wrong write used in receiver.
_exit_cleanup(code=2, file=io.c, line=1204): entered
_exit_cleanup(code=19, file=main.c, line=1182): entered
rsync error: received SIGUSR1 (code 19) at main.c(1182) [receiver=2.6.9]
_exit_cleanup(code=19, file=main.c, line=1182): about to call exit(19)
rsync error: protocol incompatibility (code 2) at io.c(1204) 
[generator=2.6.9]

_exit_cleanup(code=2, file=io.c, line=1204): about to call exit(2)

Used params: -avzR --acls --delete-after --rsh="ssh -l backup" 
[EMAIL PROTECTED]::home /backup/


Best regards,
 Sven

--
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 2.6.9 on OS X. files with xattrs don't retain mtime.

2006-11-10 Thread Wesley W. Terpstra

On Nov 10, 2006, at 11:30 AM, Matt Jenns wrote:

I'm really excited about the recent work on extended attributes. I've
compiled 2.6.9 with xattr support, and run a few tests. It seems that
if I have a file with an extended attribute ( a resource fork in this
case), and I run rsync -aX , the mtime is not preserved.

Is this the expected behaviour?


No. However, it works for me:

ottawa:~/rsync/cvs terpstra$ ./rsync -ax peanut peanut2
ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut3
ottawa:~/rsync/cvs terpstra$ stat peanut*
234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 0 "Nov 10  
15:33:02 2006" "Nov 10 15:33:02 2006" "Nov 10 15:33:12 2006" 4096 0  
0 peanut
234881035 3247791 -rw-r--r-- 1 terpstra terpstra 0 0 "Nov 10  
15:46:40 2006" "Nov 10 15:33:02 2006" "Nov 10 15:46:40 2006" 4096 0  
0 peanut2
234881035 3247792 -rw-r--r-- 1 terpstra terpstra 0 0 "Nov 10  
15:46:45 2006" "Nov 10 15:33:02 2006" "Nov 10 15:46:45 2006" 4096 0  
0 peanut3

ottawa:~/rsync/cvs terpstra$ xattr --list peanut*
peanut
foo bar
peanut2
peanut3
foo bar


What filesystem are you using? I've tried  HFS+ and UFS and both  
seemed to work.


Looking over the code, it does write extended attributes after  
setting the mtime, but I wouldn't have thought this would matter.  
Indeed, on my computer, it doesn't.

--
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: Internal error: wrong write used in receiver.

2006-11-10 Thread Wayne Davison
On Fri, Nov 10, 2006 at 02:15:22PM +0100, Sven Strickroth wrote:
> [generator] make_file(home/administ,*,2)
> Internal error: wrong write used in receiver.

Looks like the ACLs patch didn't get tested with --delete + --acls.
Applying the attached patch will fix this.

..wayne..
--- old/flist.c
+++ new/flist.c
@@ -987,7 +987,7 @@
file->mode = tweak_mode(file->mode, chmod_modes);
 
 #ifdef SUPPORT_ACLS
-   if (preserve_acls) {
+   if (preserve_acls && f >= 0) {
sx.st.st_mode = file->mode;
sx.acc_acl = sx.def_acl = NULL;
if (get_acl(fname, &sx) < 0)
@@ -1003,12 +1003,12 @@
flist->files[flist->count++] = file;
send_file_entry(file, f);
 #ifdef SUPPORT_ACLS
-   if (preserve_acls)
+   if (preserve_acls && f >= 0)
send_acl(&sx, f);
 #endif
} else {
 #ifdef SUPPORT_ACLS
-   if (preserve_acls)
+   if (preserve_acls && f >= 0)
free_acl(&sx);
 #endif
}
-- 
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 2.6.9 on OS X. files with xattrs don't retain mtime.

2006-11-10 Thread Wesley W. Terpstra

On Nov 10, 2006, at 3:55 PM, Wesley W. Terpstra wrote:

On Nov 10, 2006, at 11:30 AM, Matt Jenns wrote:

I'm really excited about the recent work on extended attributes. I've
compiled 2.6.9 with xattr support, and run a few tests. It seems that
if I have a file with an extended attribute ( a resource fork in this
case), and I run rsync -aX , the mtime is not preserved.

Is this the expected behaviour?


No. However, it works for me


Now I've reproduced it.
When one sets the ResourceFork extended attribute, that resets the  
mtime, but this is not true for other attributes. Very odd.
It makes me wonder whether on some systems updating any attribute  
could reset the mtime. If that's the case the mtime has to be set  
after the chmod!


Looking over the code, it does write extended attributes after  
setting the mtime, but I wouldn't have thought this would matter.  
Indeed, on my computer, it doesn't.


I've tried changing this (putting the mtime code after the xattr, but  
before the acl):


In direct sync case it works:

ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut3
ottawa:~/rsync/cvs terpstra$ stat peanut*
234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:57 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
16 0 peanut
234881035 3247942 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:57 2006" "Nov 10 15:57:55 2006" "Nov 10 16:09:57 2006" 4096  
16 0 peanut3


For two step updates, it still fails:

ottawa:~/rsync/cvs terpstra$ ./rsync -ax peanut peanut2
ottawa:~/rsync/cvs terpstra$ stat peanut*
234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:21 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
16 0 peanut
234881035 3247937 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:21 2006" "Nov 10 15:57:55 2006" "Nov 10 16:09:21 2006" 4096 8  
0 peanut2

ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut2
ottawa:~/rsync/cvs terpstra$ stat peanut*
234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:29 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
16 0 peanut
234881035 3247937 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:21 2006" "Nov 10 16:09:29 2006" "Nov 10 16:09:29 2006" 4096  
16 0 peanut2

ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut2
ottawa:~/rsync/cvs terpstra$ stat peanut*
234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:57 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
16 0 peanut
234881035 3247941 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
16:09:33 2006" "Nov 10 15:57:55 2006" "Nov 10 16:09:33 2006" 4096  
16 0 peanut2


That is, if you sync a file directly, it gets the mtime+fork right  
(case: peanut->peanut3).
However, if you sync a file that is identical in all respects except  
the resource fork (xattrs), then the mtime is wrong for the first  
run, but not the second (peanut->peanut2).


Let's see what Wayne has to say; maybe the reason the mtime only gets  
updated on the second run is some deep rsync magic.


--
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 slowness issues with solaris 10

2006-11-10 Thread VIJU PADMANABHAN



After installing 
rsync 2.6.8 on Solaris 10, I have noticed that it is extremely slow compared to 
older versions of rsync in solaris 8.
 
Not sure if this is 
related to Solaris 10 or rsync, but please post your experiences with rsync in 
solaris 10. Have you noticed any slowness/performance issues 
?
 
Thanks and 
Regards.
 
-- 
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 2.6.9 on OS X. files with xattrs don't retain mtime.

2006-11-10 Thread Wayne Davison
On Fri, Nov 10, 2006 at 04:18:51PM +0100, Wesley W. Terpstra wrote:
> However, if you sync a file that is identical in all respects except  
> the resource fork (xattrs), then the mtime is wrong for the first  
> run, but not the second (peanut->peanut2).

I would imagine that is because rsync didn't call stat() on the file, so
it doesn't know that the mtime changed.  We might want the set_xattr()
function to restore the file's mtime (from file->modtime) when it thinks
that the mtime of the file was affected.  Or have the set_xattr()
function change the value of the sxp->st.st_mtime variable, and have the
regular mtime-setting code come after the xattr-setting code.

..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: Internal error: wrong write used in receiver.

2006-11-10 Thread Wayne Davison
On Fri, Nov 10, 2006 at 07:16:43AM -0800, Wayne Davison wrote:
> Looks like the ACLs patch didn't get tested with --delete + --acls.

The xattrs patch has the same problem.  If someone is using xattrs.diff
(which requires acls.diff too), the attached patch fixes both the ACL
code and the xattrs code.

..wayne..
--- old/flist.c
+++ new/flist.c
@@ -998,7 +998,7 @@
file->mode = tweak_mode(file->mode, chmod_modes);
 
 #ifdef SUPPORT_ACLS
-   if (preserve_acls) {
+   if (preserve_acls && f >= 0) {
sx.st.st_mode = file->mode;
sx.acc_acl = sx.def_acl = NULL;
if (get_acl(fname, &sx) < 0)
@@ -1006,7 +1006,7 @@
}
 #endif
 #ifdef SUPPORT_XATTRS
-   if (preserve_xattrs) {
+   if (preserve_xattrs && f >= 0) {
sx.xattr = NULL;
if (get_xattr(fname, &sx) < 0)
return NULL;
@@ -1021,20 +1021,20 @@
flist->files[flist->count++] = file;
send_file_entry(file, f);
 #ifdef SUPPORT_ACLS
-   if (preserve_acls)
+   if (preserve_acls && f >= 0)
send_acl(&sx, f);
 #endif
 #ifdef SUPPORT_XATTRS
-   if (preserve_xattrs)
+   if (preserve_xattrs && f >= 0)
send_xattr(&sx, f);
 #endif
} else {
 #ifdef SUPPORT_ACLS
-   if (preserve_acls)
+   if (preserve_acls && f >= 0)
free_acl(&sx);
 #endif
 #ifdef SUPPORT_XATTRS
-   if (preserve_xattrs)
+   if (preserve_xattrs && f >= 0)
free_xattr(&sx);
 #endif
}
-- 
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 3701] rsync_xal_set: lsetxattr system.posix_acl_default failed: Permission denied

2006-11-10 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=3701


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Comment #3 from [EMAIL PROTECTED]  2006-11-10 21:39 MST ---
The latest patch also skips system.* xattrs, since they are set via non-xattr
calls.


-- 
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