On Oct 15, 2007, at 1:55 AM, Wayne Davison wrote:
On Sun, Oct 14, 2007 at 08:14:57PM +0200, Wesley W. Terpstra wrote:
I've attached a patch which does this. Currently resource forks
and finder
info get placed into an extended attribute transparently by osx
(com.apple.{ResourceFork/FinderInfo}). This patch makes another
"extended
attribute" called com.apple.CreationDate.
Thanks! I've twiddled your patch a bit and checked it in as a file in
the patches dir (for now, at least): osx-create-time.diff
I changed the storing of the data to store the time value as 12
bytes of
binary data -- 8 for the time_t value (for future expansion) and 4 for
the nsec value (which always be 0 at present).
I fail to see the advantage of a binary version. You add concerns
about byte-order and make it unreadable to a sysadmin. (I also don't
like how the ACL stuff is binary) There was no problem with 8 byte
time_t vs. 4 byte values with the other format either as it would've
been good until year 9999. If stat is textual, why not this? Saving a
few bytes is not a good reason ...
The name of the attribute was changed to com.apple.crtime96 (for
the moment) . Since it is not an official com.apple.* value, I
didn't want to use a name that Apple might choose in the future.
The name should probably go in the rsync.* namespace, but I'd need
to move the code for reading and writing the value out of lib/
sysxattrs.c into xattrs.c to do that (I believe).
Yeah, I suppose it should go in the rsync namespace too.
I also enabled the XATTR_NOFOLLOW option for {get,set}attrlist().
This option doesn't exist for these system calls. There is, however,
FSOPT_NOFOLLOW.
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
