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

2006-11-11 Thread Wesley W. Terpstra

On Nov 10, 2006, at 9:28 PM, Wayne Davison wrote:

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.


Ahh, of course. It did the stat before the setxattr, so didn't think  
the mtime needed updating, because it was correct already/before.



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.


On osx the mtime only seems to get updated if you set things in  
com.apple.*, AFAICT.

However, that's not to say there might not be more!

I just checked on FreeBSD, and it resets the mtime on EVERY attribute  
change:

[EMAIL PROTECTED] ~/rsync-cvs/rsync -a peanut peanut2
[EMAIL PROTECTED] stat peanut*
1042 4249 -rw-r--r-- 1 terpstra users 0 0 Nov 11 07:29:14 2006  
Nov 11 07:28:29 2006 Nov 11 07:28:51 2006 Nov 11 07:28:29  
2006 16384 0 0 peanut
1042 4251 -rw-r--r-- 1 terpstra users 0 0 Nov 11 07:29:40 2006  
Nov 11 07:28:29 2006 Nov 11 07:29:40 2006 Nov 11 07:28:29  
2006 16384 0 0 peanut2

[EMAIL PROTECTED] setextattr user test value peanut2
[EMAIL PROTECTED] stat peanut*
1042 4249 -rw-r--r-- 1 terpstra users 0 0 Nov 11 07:29:14 2006  
Nov 11 07:28:29 2006 Nov 11 07:28:51 2006 Nov 11 07:28:29  
2006 16384 0 0 peanut
1042 4251 -rw-r--r-- 1 terpstra users 0 0 Nov 11 07:29:40 2006  
Nov 11 07:29:58 2006 Nov 11 07:29:58 2006 Nov 11 07:28:29  
2006 16384 4 0 peanut2


So, perhaps the sensible thing to do is just assume that the mtime is  
changed if you call set_xattr at all?



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.


That makes the most sense to me, as long as there are no side-effects  
to putting the mtime code later.


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


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