The problem happened in tests when the object we deleted by hand. This commit
prevents a crash in this (already pathological) situation.

Also added more information to the logs.

To handle cta_admin ar ls

This reverts commit 35a0cf48.

This is a first version of the command which has a fixed-size return buffer,
this code still needs to be refactored to allow a result of arbitrary size.

Removes the log parameter from ListArchiveFilesCmd constructor. Elsewhere we
are using log context objects: the SSI version of the command dispatcher has
access to the lc but not the log object. In any case this was not being used
so safe to remove for the time being.

We do not do a stat before reading. Instead we ask for an arbitrarily big read, and find out
the size of the data while reading. This avoids a race condition in lockfree reads where we failed
to get the full object if it got re-written to a bigger size between stat an read.

Signed-off-by: Cristina Moraru <cristina-gabriela.moraru@cern.ch>

Signed-off-by: Cristina Moraru <cristina-gabriela.moraru@cern.ch>

Signed-off-by: Cristina Moraru <cristina-gabriela.moraru@cern.ch>

A benign exception failed to be caught and led to unnecessary errors.

The locking of the scheduler global lock is retained so only on drive can create a mount at any point in time.

Copying SSS of taped to the official location (temporary fix, should be created here on the flyx by default)

Compile switches now applied to each target separately, cta_admin has
instrumentation switched off.

Rao branch

See merge request !4

If the whole contents of the ARCHIVE_FILE and TAPE_FILE tables are
listed without a search criteria and with an ORDER BY clause then the
first row back from the database will take a relatively long period of
time to be returned.  This is because the database will have to sort
every row before returning the first.  This long period of time will
cause the current (non SSI) cta command-line tool to time out.