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).

rtcpd now supports buffered tape-marks over multiple files.

Forgot to add the test_exception class to the test/castor/tape/tapebridge test directory.

Improved unit tests.

Fixed a bug in the method castor::tape::tapebridge::TapeFlushConfigParams::determineTapeFlushConfigParams where the configuration parameters were not actually being dteremined.

After further reverse engineering rtcpd it became apparent that there should
only be one configuration parameter to specify which of the following 3 possible
tape-flush behaviours the tapebridged and rtcpd daemons should follow:

  * N_FLUSHES_PER_FILE
  * ONE_FLUSH_PER_FILE
  * ONE_FLUSH_PER_N_FILES

This commit adds the following tapebridge configuration parameter, which today
is ignored:

  TAPEBRIDGE TAPEFLUSHMODE N_FLUSHES_PER_FILE

More importantly and the real reason for this commit is the value of this
configuration parameter is now passed from the tapebridged daemon to the rtcpd
daemon via the tapeFlushMode member of the newly updated TAPEBRIDGE_CLIENTINFO2
message:

typedef struct {
  uint32_t volReqId;
  uint32_t bridgeCallbackPort;
  uint32_t bridgeClientCallbackPort;
  uint32_t clientUID;
  uint32_t clientGID;
  uint32_t tapeFlushMode;
  uint64_t maxBytesBeforeFlush;
  uint64_t maxFilesBeforeFlush;
  char     bridgeHost[CA_MAXHOSTNAMELEN+1];
  char     bridgeClientHost[CA_MAXHOSTNAMELEN+1];
  char     dgn[CA_MAXDGNLEN+1];
  char     drive[CA_MAXUNMLEN+1];
  char     clientName[CA_MAXUSRNAMELEN+1];
} tapeBridgeClientInfo2MsgBody_t;

Please note that the TAPEBRIDGE_CLIENTINFO2 has not been released in any version
of CASTOR and is therefore subject to change until the next release where it
will be frozen.

Before this fix, machines where a job could not be submitted (e.g. because of a timeout) were not removed from the server side scheduling queue. The number of unique pending jobs, derived from this queue was thus wrong.
On top, jobs that would finally fail to start (e.g. because all machines that accepted it are too full) would not answer their submitter, as the server was believing that other machines were still trying to schedule them.

This commit modifies the tapebridged/rtcpd protocol that is internal to a
tape-server.  The new version of the protocol is now capable of supporting
buffered tape-marks, though the version of rtcpd in this commit still only
supports at best one synchronised tape-mark per file, i.e. it does not support
buffered-tape marks over more than one file.

The change with respect to the previous version of to the tapebridged/rtcpd
protocol is simple.  When the rtcpd daemon knows that its client is is the
tapebridged daemon it now sends an explicit TAPEBRIDGE_FLUSHEDTOTAPE message to
the tapebridged daemon when it can guarantee one or more files have been
flushed to tape.  The tapebridge daemon will now only send
FileMigratedNotification messages to the tapegatewayd daemon for the files that
have been explicitly flushed to tape.  The PendingMigrationsStore is used to
hold back FileMigratedNotification messages until the appropriate
TAPEBRIDGE_FLUSHEDTOTAPE message has been received.  The rtcpd daemon in this
commit always does at least one synchronised tape-mark per file and sends
always sends one TAPEBRIDGE_FLUSHEDTOTAPE per file when its client is the
tapegatewayd daemon.

I broke the build with my last commit because I have a different version of the BridgeProtocolEnigine class.  Problem now fixed.

Added the class implementing the pending migrations store that will eventually be used to implement buffered tape-marks.