Created a new unit test to try and reproduce the problem seen here. It did not.
The best explanation we have is a stuck file client. As we totally fail to read data
from the tape, it makes no sense to open a file for which we have no data. So we deferred
the file opening when the first memory block arrives from the tape thread. The outputs of the
unit test showed that the file opening has been successfully deferred.

CASTOR-4751: tapeserverd does not report drive as empty and does not finish client session if user does not have migration access-rights

The error situation was already generating an exception, which went all the way to the caller
of the data transfer session. It is now intercepted and the client is notified synchronously.
The session now ends successfully (the drive was not touched).

Fixed preloading of the krb5 library after it had been renamed. Unfortunately, its name is hardcoded...

We had a session ending mechanism for the tape and disk tasks in migrations, but it did not cover all the aspects of the tape thread (like in this ticket, mounting). In this case the disk thread was happily reading the data from disk, which the tape thread was putting to the bin.

The signalling mechanism, attached to the task injector has now been passed to tape write thread itself, which signals the error condition when receiving any exception. If this came from a task as before, this is a no-op, but if we had a problem mounting, then the session will and immediately and disk threads will stop reading (also immediately).

Done.

The getting of the data-transfer configuration parameters is now logged to /var/log/castor/tapeserverd.log

Done.

CASTOR-4798: tapeserverd should internally validate the fSeq of file being currently written to tape

Added fSeq tracking to the tapeFile::WriteSession and added the corresponding
calls in the tape write task.

Replaced an ad-hoc loop by a more standard and efficient remove-erase in castor::log::LogContext::erase

The variable m_bytesBeforeFlush was erroneously set to m_castorConf.maxBytesBeforeFlush/m_castorConf.bufsz
instead of simply m_castorConf.maxBytesBeforeFlush in DataTransferSession::executeWrite. Fixed this.

I believe the Timer class is generic enough to be used by any
part of CASTOR and not just tape.

Only the tapegatewayd daemon uses the BoolFunctor class.

Only the tapegatewayd daemon uses the ShutdownBoolFunctor class.

Found and removed some left over manual page text that still
referred to the RMC/HOST configuration parameter.

Fixed

Unit tests are now implemented using gtest.  Unit tests
implemented with CppUnit are now obsolete.

The ProcessForker can impose "entire lifetime" or "per mount"
refreshes of CASTOR configuration-parameters.  There is no
need for the tapeserverd parent process to do this and send
the results over the wire.

The ProcessForker can impose "entire lifetime" or "per mount"
refreshes of CASTOR configuration-parameters.  There is no
need for the tapeserverd parent process to do this and send
the results over the wire.

The ProcessForker can impose "entire lifetime" or "per mount"
refreshes of CASTOR configuration-parameters.  There is no
need for the tapeserverd parent process to do this and send
the results over the wire.