Re: [Dar-support] Request: Dar to preserve CreateTime on OS X

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello John,

Thank you for your researches and for the detailed information you provided.

Now that we understand the problem, I must take some time to evaluate
the best way to address this issue. Libdar's software architecture lead
that Extended Attributes (EA) not to be restored before the inode is
created itself which implies setting ownership, permissions, and dates,
then EA.

First, libdar cannot use the getattrlist() / setattrlist() calls,
because they are MacOS X specific (they do not even work on all volume
as written in the documentation). Any way these are not portable calls
while dar/libdar runs on Linux, OpenSolaris, FreeBSD, Cygwin/Windows,
not only MacOS X. However, inverting the order of restoration for the
mtime and EA, should address this problem, and would stay logical
keeping in mind that that the last "modification" of the inode is
setting the last modification date

Second the problem here is more about software architecture where two
different modules manage classical inode attributes in one side and
extended inode attribute in the other side ... Anyway, I must take time
to take the most adapted path to solve this issue in regard to the
current software implementation in libdar.

Best Regards,
Denis.


John B Thiel wrote:
> Hi Denis,
> 
> 
> == Info on preserving CreateTime ==
> 
> I have researched some info on preserving the CreateTime in OS X from
> a Unix/Posix program.  A good reference is the crtimes.diff patch to
> rsync, which adds the -N/--crtimes flag, which accomplishes it.
> 
> Rsync is at http://rsync.samba.org/ftp/rsync/
> and the crtimes.diff patch is bundled in rsync-patches-3.0.8.tar.gz
> 
> The critical part of the patch is two functions that do the work, as
> below.  They use system calls getattrlist() and setattrlist(), which
> are documented here:
> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/setattrlist.2.html
> 
> ------------------------------------------------------------
> time_t get_create_time(const char *path)
> {
>        static struct create_time attrBuf;
>        struct attrlist attrList;
> 
>        memset(&attrList, 0, sizeof attrList);
>        attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
>        attrList.commonattr = ATTR_CMN_CRTIME;
>        if (getattrlist(path, &attrList, &attrBuf, sizeof attrBuf,
> FSOPT_NOFOLLOW) < 0)
>                return 0;
>        return attrBuf.crtime.tv_sec;
> }
> 
> int set_create_time(const char *path, time_t crtime)
> {
>        struct attrlist attrList;
>        struct timespec ts;
> 
>        if (dry_run) return 0;
>        RETURN_ERROR_IF_RO_OR_LO;
> 
>        ts.tv_sec = crtime;
>        ts.tv_nsec = 0;
> 
>        memset(&attrList, 0, sizeof attrList);
>        attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
>        attrList.commonattr = ATTR_CMN_CRTIME;
>        return setattrlist(path, &attrList, &ts, sizeof ts, FSOPT_NOFOLLOW);
> }
> ------------------------------------------------------------
> 
> 
> Although the rsync patch added this support as a flagged special
> option,  I strongly disagree with that default=off approach and
> consider the default and reliably constant behavior should be to
> always preserve the CreateTime when a file is
> copied/duplicated/restored -- which is how the Mac Finder works (and
> is really the only sensible thing for this vital user-visible datum).
> The confusions/omissions in posix tools apparently come from an idea
> of historically ignoring or (re-)defining createTime from a
> filesys/inode point-of-view  (which is less useful, and breaks decades
> of Mac user experience).
> 
> ie. I do not see a need to -flag this feature in Dar, and if so, the
> default should be ON (at least for Mac).
> 
> If you can get some support for this feature into the development
> version in the near-term, I will gladly fetch the CVS and test it
> while my attention is here.
> 
> 
> == Backup Bouncer testing ==
> 
> There is a good tool for testing metadata preservation on OS X,
> "Backup Bouncer" available at:
> http://www.n8gray.org/code/backup-bouncer/   and
> http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/
> 
> Here are the results I obtain for Dar 2.4.0 on HFS+, OS X 10.6.8,
> backup-bouncer-0.2.0.  ("Critical" and "Important" reflect the
> author's ranking of how important that metadata is.)  Dar performs
> very well ! (better than many mac-specific tools)  After the
> CreateTime issue, perhaps you can also investigate the "bsd-flags" and
> "finder-locks" errors  (and eventually acl if possible?).
> 
> 
> ----------
> $ ./bbouncer create-vol Src
> $ ./bbouncer create-vol Dst
> $ ./bbouncer create /Volumes/Src
> $ sudo dar -c bbsrc -R /Volumes/Src/
> $ sudo dar -x bbsrc -R /Volumes/Dst/
> 
> $ ./bbouncer verify -d /Volumes/Src/ /Volumes/Dst/
> Verifying:    basic-permissions ... ok (Critical)
> Verifying:           timestamps ... ok (Critical)
> Verifying:             symlinks ... ok (Critical)
> Verifying:    symlink-ownership ... ok
> Verifying:            hardlinks ... ok (Important)
> Verifying:       resource-forks ...
>    Sub-test:             on files ... ok (Critical)
>    Sub-test:  on hardlinked files ... ok (Important)
> Verifying:         finder-flags ... ok (Critical)
> Verifying:         finder-locks ... FAIL
> Verifying:        creation-date ... FAIL
> Verifying:            bsd-flags ... FAIL
> Verifying:       extended-attrs ...
>    Sub-test:             on files ... ok (Important)
>    Sub-test:       on directories ... ok (Important)
>    Sub-test:          on symlinks ... ok
> Verifying: access-control-lists ...
>    Sub-test:             on files ... FAIL (Important)
>    Sub-test:              on dirs ... FAIL (Important)
> Verifying:                 fifo ... ok
> Verifying:              devices ... ok
> Verifying:          combo-tests ...
>    Sub-test:  xattrs + rsrc forks ... ok
>    Sub-test:     lots of metadata ... FAIL
> ----------
> 
> Dar reported 3 errors while imaging the Src, presumably reflecting
> that those special devices don't support EAs on HFS+
> ----------
> Error reading EA for /Volumes/Src/90-fifo/some-fifo : Error retrieving
> EA list for /Volumes/Src/90-fifo/some-fifo : Operation not permitted
> Error reading EA for /Volumes/Src/95-devices/devvn0 : Error retrieving
> EA list for /Volumes/Src/95-devices/devvn0 : Operation not permitted
> Error reading EA for /Volumes/Src/95-devices/devzero : Error
> retrieving EA list for /Volumes/Src/95-devices/devzero : Operation not
> permitted
> ----------
> 
> -- jbthiel
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Dar-support mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-support
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFODcbSpC5CI8gYGlIRAlJkAKCuoWiBEFWy4Tkgq+ahL032kauangCfaFa4
Wca6xhM3bEgaxF12sp8q56k=
=JP1T
-----END PGP SIGNATURE-----