AFS-Command

 view release on metacpan or  search on metacpan

Changes.html  view on Meta::CPAN


<P>

<P>
<HR>
<H2><A NAME="AFS_Command_VOS_restore_argum">AFS::Command::VOS->restore arguments added

</A></H2>
Documentation for two important new vos restore arguments was added to the
documentation (-creation and -lastupdate). These options are only available
in a patch to vos, which should be in one the next two major OpenAFS 1.2.X
releases.


<P>

<P>
<HR>
<H1><A NAME="Bugs">Bugs

</A></H1>
<P>
<HR>
<H2><A NAME="AFS_Object_VolumeHeader_acces">AFS::Object::VolumeHeader 'accesses' attribute was incorrect

</A></H2>
The actual attribute on the objects was named ``access''. Oops. The
attribute was changed to ``accesses'' to match the documentation, and the
string that is parsed in vos output.


<P>

<P>
<HR>
<H1><A NAME="Changes_in_1_4">Changes in 1.4

</A></H1>
<P>
<HR>
<H1><A NAME="Enhancements">Enhancements

</A></H1>
<P>
<HR>
<H2><A NAME="Test_suite_is_disabled_by_defaul">Test suite is disabled by default.

</A></H2>
There is a well intentioned effort to automatically test all new
submissions to CPAN (see <A
HREF="http://testers.cpan.org).">http://testers.cpan.org).</A>
Unfortunately, the AFS-Command package can't be tested automatically, since
it requires a fair amount of configuration. You have to specify a cell
name, some fileserver names and partitions, etc.


<P>

By default, the tests will all be skipped if the configured cell name in
the CONFIG file has not been modified, thus allowing the automated CPAN
testing to continue, automatically, without the author getting a bunch of
bogus emails.


<P>

<P>
<HR>
<H1><A NAME="Bugs">Bugs

</A></H1>
<P>
<HR>
<H2><A NAME="Volume_status_value_inconsistenc">Volume status value inconsistency

</A></H2>
!!!!!!!! WARNING !!!!!!!!


<P>

This change is NOT backwards compatible with previous releases, so verify
that your code handles the new, consistent values correctly.


<P>

The ``status'' field returned from either vos-&gt;examine() or
vos-&gt;listvol(), in previous releases, had inconsistent values. When a
volume is online, the status would be one of:


<P>

<PRE>    online
    On-line
</PRE>

<P>

Likewise, when offline, one of:


<P>

<PRE>    offline
    Off-line
</PRE>

<P>

These values have all been normalized to: online, offline


<P>

<P>
<HR>
<H2><A NAME="AFS_Command_VOS_examine_parse">AFS::Command::VOS->examine parses busy and offline messages

</A></H2>
When a volume is busy or can not be attached, ``vos examine'' will be
unable to display the volume headers. Instead, a one line message is
printed, such as one of the following:


<P>

<PRE>    **** Volume 123456789 is busy ****
    **** Could not attach volume 123456789 ****
</PRE>

<P>

The examine method now parses these, and the AFS::Object::VolumeHeader
object will have only the 'id' and 'status' attributes. Previously, those
lines were incorrectly parsed and the 'name' attribute set to '****', which
is pretty obviously wrong.


<P>

<P>
<HR>
<H1><A NAME="Changes_in_1_3">Changes in 1.3

</A></H1>
<P>
<HR>
<H1><A NAME="Enhancements">Enhancements

</A></H1>
<P>
<HR>
<H2><A NAME="AFS_Command_VOS_release_suppo">AFS::Command::VOS->release support both -f and -force

</A></H2>
Someone at some point changed vos release's force argument from -f to
-force. API calls written with one of those will not work with a vos binary
that doesn't agree on the choice of force option. This would have require
developers to write code like this:


<P>

<PRE>   $vos-&gt;release
     (
      id                =&gt; $id,
      cell              =&gt; $cell,
      ( $vos-&gt;supportsArgument('release','force') ?
        ( force         =&gt; 1 ) :
        ( f             =&gt; 1 )
      ),
     );
</PRE>

<P>

OK, that's the authors twisted way of doing it, and it seems like needless
complexity. Both f and force are now supported as options, using a simply
alias mechanism to translate from one to the other, based on what is
supported by the vos binary.


<P>

The documentation hasn't been changed, since you can use 'force' in all
cases, and since that is the newer of the two, the docs will stay as they
are. The fact that your vos binary really wants 'f' is hidden from you, and
will stay that way.


<P>

<P>
<HR>
<H1><A NAME="Bugs">Bugs

</A></H1>
<P>
<HR>
<H2><A NAME="AFS_Command_BOS_listhosts">AFS::Command::BOS->listhosts

</A></H2>
The returned object has a cell attribute, as well as the hosts attribute,
but the docs forgot to mention this.


<P>

<P>
<HR>
<H1><A NAME="Changes_in_1_2">Changes in 1.2

</A></H1>
<P>
<HR>
<H1><A NAME="Enhancements">Enhancements

</A></H1>
<P>
<HR>
<H2><A NAME="AFS_Command_VOS_offline_and">AFS::Command::VOS->offline() and ->online()

</A></H2>
Both of these ``hidden'' vos commands are now supported by the API. These
commands are part of the vos command suite, but they do not show up in the
output of ``vos help''.


<P>

<P>
<HR>
<H1><A NAME="Bugs">Bugs

</A></H1>
<P>
<HR>



( run in 1.377 second using v1.01-cache-2.11-cpan-5c0b1e786e0 )