On Thursday 18 November 2010 20:40:13 Bakul Shah wrote: > On Wed, 17 Nov 2010 09:44:27 PST David Leimbach <[email protected]> wrote: > > On Wed, Nov 17, 2010 at 9:23 AM, dexen deVries > > <[email protected]>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.
thanks ;) -- dexen deVries ``One can't proceed from the informal to the formal by formal means.''
