Snow Leopard svn problems

September 16th, 2010

A month or so ago I noticed that when I ran ‘svn –version’ I would get this:

$ svn --version
svn: Mismatched RA version for 'neon': found 1.6.2, expected 1.6.5

I did some basic googling and decided the easiest solution was to install a newer version from macports. However, today I decided to revisit this and actually try to solve it since I was moving from macports to homebrew. I found this nice article that suggested re-installing the 10.6.2 Combo update would resolve the problem. That sounds like a horrible idea since I’m no longer running 10.6.2 and who knows what that would break down the road, but I went ahead and downloaded the update to look at the contents. Using Pacifist I opened the installer package and had it verify that the svn binaries and libraries were all alright and they all passed with out a complaint. This didn’t make sense because clearly something was wrong with one of the libraries or binaries for subversion. After a little while I decided to have Pacifist re-install the svn binaries and libraries from the update to see if it fixed the problem. Before I did this I checked the other OS X update receipts to see if the subversion binaries or libraries have been modified since the 10.6.2 update and found they hadn’t. After the re-install everything looks like it’s back to normal! So, if you are having this issue and don’t want to use a newer version, grab the 10.3.2 combo update and Pacifist and go to town.

FYI the binaries and libraries for subversion include:


/usr/bin/svn
/usr/bin/svnadmin
/usr/bin/svndumpfilter
/usr/bin/svnlook
/usr/bin/svnserve
/usr/bin/svnsync
/usr/bin/svnversion
/usr/lib/libsvn_client-1.0.0.0.dylib
/usr/lib/libsvn_client-1.0.dylib
/usr/lib/libsvn_client-1.dylib
/usr/lib/libsvn_delta-1.0.0.0.dylib
/usr/lib/libsvn_delta-1.0.dylib
/usr/lib/libsvn_delta-1.dylib
/usr/lib/libsvn_diff-1.0.0.0.dylib
/usr/lib/libsvn_diff-1.0.dylib
/usr/lib/libsvn_diff-1.dylib
/usr/lib/libsvn_fs-1.0.0.0.dylib
/usr/lib/libsvn_fs-1.0.dylib
/usr/lib/libsvn_fs-1.dylib
/usr/lib/libsvn_fs_fs-1.0.0.0.dylib
/usr/lib/libsvn_fs_fs-1.0.dylib
/usr/lib/libsvn_fs_fs-1.dylib
/usr/lib/libsvn_fs_util-1.0.0.0.dylib
/usr/lib/libsvn_fs_util-1.0.dylib
/usr/lib/libsvn_fs_util-1.dylib
/usr/lib/libsvn_ra-1.0.0.0.dylib
/usr/lib/libsvn_ra-1.0.dylib
/usr/lib/libsvn_ra-1.dylib
/usr/lib/libsvn_ra_local-1.0.0.0.dylib
/usr/lib/libsvn_ra_local-1.0.dylib
/usr/lib/libsvn_ra_local-1.dylib
/usr/lib/libsvn_ra_neon-1.0.0.0.dylib
/usr/lib/libsvn_ra_neon-1.0.dylib
/usr/lib/libsvn_ra_neon-1.dylib
/usr/lib/libsvn_ra_svn-1.0.0.0.dylib
/usr/lib/libsvn_ra_svn-1.0.dylib
/usr/lib/libsvn_ra_svn-1.dylib
/usr/lib/libsvn_repos-1.0.0.0.dylib
/usr/lib/libsvn_repos-1.0.dylib
/usr/lib/libsvn_repos-1.dylib
/usr/lib/libsvn_subr-1.0.0.0.dylib
/usr/lib/libsvn_subr-1.0.dylib
/usr/lib/libsvn_subr-1.dylib
/usr/lib/libsvn_swig_ruby-1.0.0.0.dylib
/usr/lib/libsvn_swig_ruby-1.0.dylib
/usr/lib/libsvn_swig_ruby-1.dylib
/usr/lib/libsvn_wc-1.0.0.0.dylib
/usr/lib/libsvn_wc-1.0.dylib
/usr/lib/libsvn_wc-1.dylib

SpiderOak Backup Bouncer tests

July 21st, 2010

I really want to like SpiderOak, especially when you consider the following features:

  • Whole cloud de-duplication – All of the data you backup to spideroak, regardless of the source is de-duplicated
  • The ability to share files in your cloud with others
  • ‘Zero-knowledge’ encryption
  • Cross platform client
  • Support of open source

However, I keep finding problems that prevent me from using it as my primary backup software. As with BackBlaze I did some testing with Backup Bouncer v0.2.0 to see how the latest version of SpiderOak (v3.6.9680) fairs with the meta-data that Mac OS X generates. Results follow.

sh-3.2# ./bbouncer verify -d /Volumes/Src ../Dst
Verifying:    basic-permissions ... FAIL (Critical)
Verifying:           timestamps ... FAIL (Critical)
Verifying:             symlinks ...
    stat: ./symlink1: stat: No such file or directory
    FAIL (Critical)
Verifying:    symlink-ownership ... FAIL 
Verifying:            hardlinks ... FAIL (Important)
Verifying:       resource-forks ... 
   Sub-test:             on files ... FAIL (Critical)
   Sub-test:  on hardlinked files ... FAIL (Important)
Verifying:         finder-flags ... FAIL (Critical)
Verifying:         finder-locks ... FAIL 
Verifying:        creation-date ... FAIL 
Verifying:            bsd-flags ... FAIL 
Verifying:       extended-attrs ... 
   Sub-test:             on files ... FAIL (Important)
   Sub-test:       on directories ... FAIL (Important)
   Sub-test:          on symlinks ... FAIL 
Verifying: access-control-lists ... 
   Sub-test:             on files ... FAIL (Important)
   Sub-test:              on dirs ... FAIL (Important)
Verifying:                 fifo ... FAIL 
Verifying:              devices ... FAIL 
Verifying:          combo-tests ... 
   Sub-test:  xattrs + rsrc forks ... FAIL 
   Sub-test:     lots of metadata ... FAIL 

As you can see, SpiderOak fails all of the backup-bouncer tests. Combine this with the password issues I’ve mentioned previously and it looks like SpiderOak still has a ways to go before I can seriously consider using it to house my data.

BackBlaze and metadata

March 22nd, 2010

Last night I did some testing on BackBlaze with backup-bouncer v0.2.0 to see how well it was preserving the extra meta-data HFS+ is capable of storing. The results were rather shocking:

./bbouncer verify -d /Volumes/Src ~volz/Downloads/Src
Verifying:    basic-permissions ... FAIL (Critical)
Verifying:           timestamps ... FAIL (Critical)
Verifying:             symlinks ... 
    stat: ./symlink1: stat: No such file or directory
    FAIL (Critical)
Verifying:    symlink-ownership ... FAIL 
Verifying:            hardlinks ... FAIL (Important)
Verifying:       resource-forks ... 
   Sub-test:             on files ... ok (Critical)
   Sub-test:  on hardlinked files ... FAIL (Important)
Verifying:         finder-flags ... FAIL (Critical)
Verifying:         finder-locks ... FAIL 
Verifying:        creation-date ... FAIL 
Verifying:            bsd-flags ... 
    stat: ./dir-with-flags: stat: No such file or directory
    FAIL 
Verifying:       extended-attrs ... 
   Sub-test:             on files ... FAIL (Important)
   Sub-test:       on directories ... FAIL (Important)
   Sub-test:          on symlinks ... FAIL 
Verifying: access-control-lists ... 
   Sub-test:             on files ... FAIL (Important)
ls: ./acl-test-dir: No such file or directory
   Sub-test:              on dirs ... FAIL (Important)
Test dir '/Users/volz/Downloads/Src/90-fifo' does not exist
Test dir '/Users/volz/Downloads/Src/95-devices' does not exist
Verifying:          combo-tests ... 
   Sub-test:  xattrs + rsrc forks ... FAIL 
   Sub-test:     lots of metadata ... FAIL

No basic permissions? No timestamps? And no extended attributes? Wow, this means restores from BackBlaze will only get your data back and that you loose all of the hidden data on your files… What does this mean? Well, for example if you have a file that is locked and you restore it, the new file won’t be locked. Examples of other things that get lost: whether or not a file extension is hidden, creation dates, modify dates, symlinks, if a downloaded file hasn’t been opened yet (quarantined), finder comments and where you downloaded an item from. What is the logic here? Is it really that much effort to back this up? Too much space used if you back this up? I wonder how Mozy fares in this test.