Re: [OpenAFS] Re: Extract files from /vicepa

[Germán Ferrari]

On Fri, Jan 17, 2014 at 2:45 PM, Andrew Deason adea...@sinenomine.netwrote:

 On Fri, 17 Jan 2014 11:05:33 +
 Germán Ferrari german.ferr...@gmail.com wrote:

  If I understood correctly, the easiest way to restore the files is to
  setup another afs server and just overwrite the /vicepa folder with
  the one I have. Is this correct?

 There is at least one other way to extract the data, without needing to
 set up a server. You can use the 'voldump' utility to construct a volume
 dump from the /vicepa data, and you can use afsdump_extract to convert
 the volume dump to a tree of actual files. You'll still probably need a
 unixy machine for this, though.

 'voldump' is a part of openafs, and you should get it with the openafs
 packages for your platform. See
 http://docs.openafs.org/Reference/8/voldump.html

 'afsdump_extract' is part of dumpscan. You can either use the copy of
 dumpscan that's in the OpenAFS tree, or you can get it from here:
 http://grand.central.org/dl/software/dumpscan/, or there's also a tree
 with a few fixes that have been collected here:
 https://github.com/openafs-contrib/cmu-dumpscan/tree/fixes


Excelent news.

I will try to play with this as soon as get back to work with the machines.

Thank you.


Germán

Re: [OpenAFS] Re: Extract files from /vicepa

[Jeffrey Hutzelman]

On Fri, 2014-01-17 at 14:41 -0600, Andrew Deason wrote:
 On Fri, 17 Jan 2014 19:57:55 +0100
 Stephan Wiesand stephan.wies...@desy.de wrote:
 
  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.
 
 Do you mean under openafs.git, or something else? I plan on looking at
 that CVS repo and putting the changes into git somewhere, but I hadn't
 yet thought that it would go into openafs.

So, part of the problem with just merging the improvements is that
that github repository doesn't contain the complete history; it was
created by importing the 1.2 tarball.

It would certainly be possible for someone to merge the changes into
OpenAFS, but I'd rather not.  I do not subscribe to the notion that
every AFS-related tool needs to be part of the OpenAFS distribution.


  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?
 
 No, the licensing seems pretty permissive. I thought there was some
 desire to have some of the simpler tooling separate from OpenAFS itself,
 like some of the other stuff in openafs-contrib. The README text makes
 it pretty clear that at least the original authors wanted that; I
 thought that jhutz and some users might agree with that, as well.

In the case of dumpscan, I _am_ the original author.  The code was
originally written prior to the release of OpenAFS, and was intended to
be distributed separately and not depend on AFS.  It does contain rx and
com_err dependencies today, but the former is needed only for a feature
that could easily be made optional, and the latter can be satisfied from
other sources.



In any case, I've been asked to produce a real repository, and will try
to do so soon.  At that point, it should be fairly easy to merge in the
changes that are in the openafs-contrib repo, and do a release.  In the
meantime, as always, patches are welcome.

-- Jeff

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info