On Wed, 17 Nov 2010 09:44:27 PST David Leimbach <leim...@gmail.com> wrote: > > On Wed, Nov 17, 2010 at 9:23 AM, dexen deVries <dexen.devr...@gmail.com>wrote > : > > > On Wednesday 17 November 2010 18:14:35 Venkatesh Srinivas wrote: > > > (...) > > > I'd be very careful with vac -m and -a on Unix; both have been at the > > > root of considerable data-loss on a unix venti for me. I'd recommend > > > vac-ing tarballs, rather than using vac's on unix trees directly. But > > > your mileage may vary... > > > > > > could you please elaborate a bit about that data loss? > > traversing symlinks breaks? some files not getting read by vac at all? > > > > (I'm interested in using p9p vac+venti in similar manner, but on Linux w/ > > GNU stuff) > > I could imagine vac/unvac not dealing with resource forks or POSIX extended > attributes and such properly, as well as potentially having difficulty with > symlinks, but having dealt with stuff like that in "xar", I don't think it's > too difficult to address. > > I may need to read up on venti and see what sorts of data types it supports. > Might be time to add some extensions?
venti doesn't care but vac/unvac do deal with symlinks, fifos and special devices. The problem with -a is that a yyyy/mmdd/ prefix gets prepended to all paths and these dirs are readonly (555). unvac coredumps in trying to extract anything under yyyy/. The real problem is that unvac needs to handle non-empty 555 dirs specially (like tar does). Try this on unix: mkdir -p a/b chmod 555 a tar cf - a | (cd /tmp; tar -xvf -) vac a | (cd /tmp; unvac -v) The basic problem is that venti & friends need some grunt work to make them bullet/idiot proof.
