AFS-Command
view release on metacpan or search on metacpan
#-*-cperl-*-
#
# $Id: Changes,v 11.1 2004/11/18 17:24:53 wpm Exp $
#
# (c) 2003-2004 Morgan Stanley and Co.
# See ..../src/LICENSE for terms of distribution.
#
=head1 CHanges in 1.9
=head1 Enhancements
A new argument is supported by AFS::Command::Base->new():
my $vos = AFS::Command::VOS->new( timestamps => 1 );
This will result in ISO timestamps being prepended to each line of
output when it is collected into the $vos->errors(). This is useful
for profiling the performance of operations such as vos release:
my $result = $vos->release
(
id => 'somevol',
cell => 'somecell',
) || die $vos->errors();
When this works, the $vos->errors() will have the verbose output,
which can be logged even in the successful case, for diagnostics.
Here's an example for a failure:
[2004-11-18 17:20:36] Could not lock the VLDB entry for the volume 536998569.
[2004-11-18 17:20:36] VLDB: no permission access for call
[2004-11-18 17:20:36] Error in vos release command.
[2004-11-18 17:20:36] VLDB: no permission access for call
=head1 Changes in 1.8
=head1 Bug Fixes
=head2 vos examine did not pick up the LOCKED flag
The code to parse the VLDB header was missing the LOCKED flag, if it
was present, so this attribute was not being set properly. It is now.
=head2 pts membership error checking was bogus
Well, it still is bogus, actually, since the code has to deal with the
fact that pts has never produced meaningful return codes, so a failed
pts membership command can still exit 0, and we have to figure out if
it failed by other means. This is done by looking for the known error
messages that pts prints out, which is a good example of why parsing
the ASCII test output of commands like this is a weak architecture.
=head1 Changes in 1.7
=head1 Enhancements
=head2 Boolean flags can be turned off, as well as on
If an argument to a method (and its corresponding command line
argument) doesn't take a value, it is treated like a Boolean flag.
However, the code used to assume that the existence of a Boolean key
in the argument list implied the Boolean argument was always true.
Now, the truth of the arguments I<value> is tested to determine if the
flag should be set on or off. This makes it easy to have subroutines
that just blindly pass certain arguments along, without haing to test
them, and allows for much cleaner code.
For example:
my $result = $vos->release
(
name => $name,
force => $force,
);
Will work as you probably expected it to, namely if $force is zero, it
will NOT be passed to the "vos release" command. In previous
releases, regardless of the value of $force, the mere existence of the
force key in the argument hash would have caused the -force option to
be used.
=head1 Bugs
=head2 vos examine by numeric ID did not parse Volume Headers
The code to parse the volume headers in the output from "vos examine"
was looking for a pattern match based on the "id" argument. However,
the headers always print the name first, and we were assuming that the
id argument was the volume name, when it can also be the volume ID.
The parsing is less strict now, and works for both a volume name od a
numeric ID.
=head1 Changes in 1.6
=head1 Enhancements
=head1 AFS::Object::VolumeHeader: new attribute 'attached'
When a volume's status is "offline", there is really more than one
status the volume can be in. A volume might be unattached, and
offline, or it might be attached, but adminitratively offline. For
example, "vos offline" put a vlume in the latter state, and if for
some reason there are two volumes with the same ID on the same
fileserver, they will both be attached (if possible), but only the
first one encountered will be brought online.
Changing the value of status would been a non-backwards compatible
change, and caused some subtle problems for some applications. Rather
than introduce such a change, I have chosen to represent this state
with an additional attribute "attached", which is just a Boolean,
indicating whether or not the volume is attached.
=head1 Bugs
=head1 Changes in 1.5
=head1 Enhancements
=head2 Principal names, as user supplied arguments, are lowercased
As a convenience, when PTS names are passed to methods like
getUserByName(), they will be lower-cased before looking up the user,
or group. Since PTS is a case-insensitive database, this will avoid
( run in 3.177 seconds using v1.01-cache-2.11-cpan-cdf2f3d4e48 )