Done.

Fixed.

Small fixes for CDB commands to work correctly with Spectra library and  mhvtl.
As soon as a Spectra library and Virtual Tape Library are close loop libraries it was added special vriable to castor.conf to switch to this logic.
Right now it is just a fix for human presentation of loaded drives.

Also was fixed incorect error handling for 0xB6 CDB command.

Improved syntax do that it works with Python 2.4.3 which is the version installed on the CASTOR development boxes.

I incorrectly assumed the "no more work" file entry in the list of files to be
migrated had the same tape-file sequence-number as the last file written to
tape, in other words the file just before the "no more work" file entry.

be different in two different places.  I have now replaced the K and R
declaration with a compatible Ansi C version.

rfio/lun2fn.c:33: error: ‘char* lun2fn’ redeclared as different kind of symbol
rfio_api.h:239: error: previous declaration of ‘char* lun2fn(int)’

Arranged files to be compiled into alphabetical order as the list is getting too long to easily to find individual files by eye.

Added missing positionCommandCode member to BaseFileInfoStruct.

Added new bulk messages to RH.xmi and auto-generated the associated classes.  Please note that there is no graphical information in RH.xmi concerning the new messages because gencastor went mad and changed the order of the members of existing classes.  We now add new content manually for readablility, sanity and maintainability.

Fixed.

Fixed bug #85869: incomplete listtransfers -p output with 'Caught exception : need more than 3 values to unpack'

The cancelRecallForTape procedure has been extended to also change the status of the tape involved in the
DB. This will prevent rtcpclientd from looping on the vmgr.

The procedure cancelRecall has been made safer in the process as in some (unusual, but possible) cases, it would have killed migrations too, if any.

Improved comments within the example castor.conf file.

Added assertions to tapebridged that check the tape-file sequence-number of
the flush messages from rtcpd.

Added missing setObjType(castor::OBJ_TapeAccessSpecification) to the method
named castor::db::ora::OraVdqmSvc::selectTapeAccessSpecifications().

castor.conf file rather than relying on one being installed in the
/etc/castor/directory.

connects to the vmgrd daemon if you have one.

to Sebastien for spotting these.

bug #85285: tapegateway::WorkerThread::handleMigrationUpdate blindly sends a positive acknowledgements

Fixed the failing VMGR update when the tape was disabled. Reduced the cases when the vmgr helper functions refuse to work.
The vmgr helper class of the tape gateway was heavily refactored in the process.
Also added a mechanism to prevent looping on vmgr in case of a shutdown of the demon.
This was implemented with a new functor in tape/utils.
Homogenized the authorship information in tape gateway directory (to castor-dev team).

bug #85285: tapegateway::WorkerThread::handleMigrationUpdate blindly sends a positive acknowledgements

Changed some const on the BoolFunctor and created an implementation for tracking shutdowns. Adapter the tapebridge accordingly (const correctness).

bug #85285: tapegateway::WorkerThread::handleMigrationUpdate blindly sends a positive ackowledgements

Moved BoolFunctor from the castor::tape::tapebridge package to the
castor::tape::utils package.

bug #85285: tapegateway::WorkerThread::handleMigrationUpdate blindly sends a positive ackowledgements

This function has been reworked, to not use a blanket-defined response and instead send back the needed one. On very big try-catch
has been simplified.

bug #84322: Lack of per-file error reporting system in tapegtewayd/tapebridged

Changed log message for new error report (was identical in 2 cases).

There was only one instance of a positive response which should have been negative (VMGR failure).