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 protected]> 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… >>> >>> I’ve currently got a bunch of old data (couple hundred gigs maybe) from vos >>> dump that I’d like to be able to examine to see exactly what’s there >>> anymore. Right now, my personal cell lives on a couple VMs out in various >>> public clouds, and I haven’t 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 later. >> >> 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 to > date and contain some significant bugs. I asked Derrick at the time not > 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' > module. > > I suppose if sufficiently prodded, I could probably be convinced to > convert this to git, post it someplace more easily accessible, and do a > release. In a perfect world, Andrew would now pick up your CVS repository, merge the 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 this being part of our regular OpenAFS releases. Obviously, there's a real need for these tools. Are there any licensing obstacles? - Stephan_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
