Now, the truth of the arguments 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.
The parsing is less strict now, and works for both a volume name od a numeric ID.
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.
getUserByName(), they will be lower-cased before looking up
the user, or group. Since PTS is a case-insensitive database, this will
avoid the need for applications to lc() some strings, although
not in all cases.
For example, you can pass a mixed case string to pts->creategroup(), and
then use the same string to query the resulting AFS::Object::Group object
using getGroupByName().
The object's ``group'' attribute, however, will be in lower case, since that will be the value returned by the pts command itself.
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.
This change is NOT backwards compatible with previous releases, so verify that your code handles the new, consistent values correctly.
The ``status'' field returned from either vos->examine() or vos->listvol(), in previous releases, had inconsistent values. When a volume is online, the status would be one of:
online
On-line
Likewise, when offline, one of:
offline
Off-line
These values have all been normalized to: online, offline
**** Volume 123456789 is busy ****
**** Could not attach volume 123456789 ****
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.
$vos->release
(
id => $id,
cell => $cell,
( $vos->supportsArgument('release','force') ?
( force => 1 ) :
( f => 1 )
),
);
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.
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.
getVLDBEntryById($id)
getVLDBEntryByName($name)
getVolumeIds()
The API for getVLDBEntry has changed, and the single argument usage:
getVLDBEntry($name) # DEPRECATED!!!!
has been deprecated. If warnings are enabled (perl -w), then the API will carp at you. In the next release (1.2), that usage will no longer be supported. Upgrade your code, or pay the price.
The new usage of getVLDBEntry is one of:
getVLDBEntry( name => $name )
getVLDBEntry( id => $id )
The internal method _addEntry() now manages the data by id as
well as name, but you're not supposed to know that anyway...
whichcell(),
then the error handling was a bit intrusive. The way it used to work, in
1.0, was to return an error if we didn't see output for one or more of the
paths. Now, the code is more forgiving, and if have no idea what happened
for one of the given paths, we'll return a Path object for that path which
has a generic error.