[OpenAFS] Extract files from /vicepa
Fri, 17 Jan 2014 19:57:55 +0100
On Jan 17, 2014, at 19:35 , Jeffrey Hutzelman wrote:
> On Fri, 2014-01-17 at 16:52 +0100, Stephan Wiesand wrote:
>> On 2014-01-17, at 16:43, Coy Hile <email@example.com> wrote:
>>>> I have a perl script from 2005 that could do this - but only for =
pure r/w volumes. If there's a backup or readonly clone on the same =
partition, it will probably fail miserably. It's not polished, may have =
to be adapted to current perl versions etc. And I think it recovered =
nothing but the file content and the path, not mode/owner/ACLs...
>>>> Setting up a server is certainly the better option and may well be =
easier and faster. But if you're desperate enough, let me know.
>>> along not completely dissimilar lines=85
>>> I=92ve currently got a bunch of old data (couple hundred gigs maybe) =
from vos dump that I=92d like to be able to examine to see exactly =
what=92s there anymore. Right now, my personal cell lives on a couple =
VMs out in various public clouds, and I haven=92t got around to standing =
up a fileserver inside the firewall yet.
>>> is there a tool (preferably stand-alone) that I could run on those =
old dumps to copy the data out of them into a local directory on, say, =
my mac. Then I can copy whatever of it I want to keep back into AFS =
>> afsdump_scan and afsdump_extract are part of the OpenAFS source tree
>> but not built by default. They build fine (there are make targets for
>> them) and basically work. There's an improved version by jhutz in
>> /afs/grand.central.org/software/dumpscan/dumpscan-1.2.tar.gz that was
>> more difficult to build IIRC.
> The versions in the openafs source are ancient copies that were put
> there as part of an effort to develop a test suite. They are not up =
> date and contain some significant bugs. I asked Derrick at the time =
> to fork this, but he chose to do so anyway.
They serve a purpose by just making us aware these tools exist.
> The latest released version is 1.2, but I more or less have enough
> changes to do a 1.3 release, including a couple of bug fixes, a couple
> of new features, and somewhat better ability to build against newer
> OpenAFS. The build system is not terribly polished, but the tools do
> work. A CVS repository can be found in
> /afs/cs.cmu.edu/project/systems-jhutz/Repository in the 'dumpscan'
> I suppose if sufficiently prodded, I could probably be convinced to
> convert this to git, post it someplace more easily accessible, and do =
In a perfect world, Andrew would now pick up your CVS repository, merge =
improvements into the github one he mentioned, and start submitting the
results to gerrit.openafs.org. I'd love to see the state of the art of =
being part of our regular OpenAFS releases. Obviously, there's a real =
for these tools.
Are there any licensing obstacles?