in 70-xar.cp you have hardcoded the location of xar as /usr/local/dports/bin/xar. but the default location for darwinports is to put it at /opt/local/bin/xar. how about using `which xar`?

I just tried xar from darwinports (1.5) and it seems to try to hide the data until the archive is all complete. Very strange. The only relevant file I could see using `lsof` was the archive file, but it was always 0 bytes until it was finished. I’m guessing it created a temp file and then used extended attributes to hide it.

@ray: Since xar isn’t installed with OS X I just hardwired it for my own system. I really despise the way macports and fink add random new branches to the filesystem root (though opt is not without precedent) when /usr/local is already a well-accepted place for this sort of thing. Anyhow, I’ll probably change it to use ‘which’, though that always makes me a bit nervous — I often end up with different versions of things installed in different paths (thanks to having both macports and fink on my system).

@becks: I can’t say I’ve looked at this behavior. Is this important to you?

Unless you specify verbose output, there’s no indication of any progress, besides using “df”.

Hmmm, I’m not getting the same result, but then I’m also getting an error earlier on.

Am I doing something wrong? This is with current SVN head (2007-Aug-06) on Tiger, with the 0.1.1 scripts. xar 1.5.1 also seems to fail in the same way.

———————————-

# ./bbouncer create-vol Src; ./bbouncer create-vol Dst
# ./bbouncer create /Volumes/Src (All OK)
# ./bbouncer copy -c 70-xar -d /Volumes/Src /Volumes/Dst
src = /Volumes/Src
dst = /Volumes/Dst
Enabling owners on src/dst disks
Password:
/dev/disk5s2 on /Volumes/Src (local, journaled, mounted by pauls)
/dev/disk6s2 on /Volumes/Dst (local, journaled, mounted by pauls)
Cleaning.
Copying with: xar … touch: /Volumes/Dst/70-xar/bbouncer-vol: Permission denied
ok

—————— xar ——————
Verifying: basic-permissions … FAIL
Verifying: timestamps …
Sub-test: modification time … ok
ok
Verifying: symlinks … ok
Verifying: symlink-ownership … FAIL
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 … ok
Verifying: devices … ok
Verifying: combo-tests …
Sub-test: xattrs + rsrc forks … ok
Sub-test: lots of metadata … FAIL
FAIL

@Paul: It looks like I had forgotten the -P flag to xar in the 0.1.1 release. You can add it in copiers.d/70-xar.cp in the backup function. It’s fixed in svn, so I’ll roll up a new release when I have a chance.

@n8: Thanks, I’d dug around and found that out, but now you’ve added the aliases test, so xar no longer gets a clean sweep

Reckon it probably does better than a lot of things out there though. The only problem is that it doesn’t re-home the alias. Good enough for backups though where you expect to restore to the same location.

Great suite of tests btw. Really useful stuff on something really important.

@Paul: Yeah, don’t read too much into the alias test at the moment. It’s not clear what the correct behavior is for aliases, or even if there *is* a correct behavior. I know how I would want them handled: if an alias is pointing to a backed-up file then it should point to the corresponding restored file, even if it’s at a different path. However, I can see somebody wanting different behavior. My lab-mate thought that retaining the original target was the right thing to do. (BTW, the exact same debate applies to absolute symlinks, which I don’t have a test for in the symlink tests.)

I should probably introduce a type of test that’s not pass-fail for cases like this where you want to understand how the tool behaves but there’s not a clear right or wrong behavior.