At 02:53 AM 5/01/2007, you wrote:

>The Linux machine is running SuperServer - same as the PC

Could you check that again? The command as used below should fail
under Superserver.

>command to restore was
>GBAK -REP -VER -i -USER XXX -PAS xxx source.fbk destin.fdb
>
>works with the -i but the resultant file cannot enable indexes,
>without it fails on the indexes - ie same both ways.

I lean towards Paul's and Ann's idea that there is an access or
capacity problem with your /temp directory. It would account for the
blank file name in the error message: the engine creates temporary
sort files using an internal naming algorithm...first you get an i/o
error because [whatever user - see below] doesn't have the
permissions. (If the engine had been able to create the empty file
at all, we would not see a blank file name in the error message....)

But there could be more to it. The command above would be expected
to fail under SS on two, possibly three counts. I asked you to
provide the exact command that you used so, if that is what you
provided here, then gbak would be expected to fail somewhere, for
several possible reasons:

1) SS requires a remote connection. The fact that gbak is running
and is able to succeed in creating a database file and writing data
to it suggests that possibly you have an old copy of libfbembed.so in
the file path that gbak is using to connect directly using a Classic process.

2) AFAIU, the new security measures in Fb 2.0 do not allow access to
databases via an unqualified file path. That suggests (from a
different angle) the possibility that gbak is not using Fb 2.0's
libfbclient.so library but some artifact from a previous Classic installation.

3) A superserver client cannot access a database via a direct
connection - DC is [ or is meant to be ] possible only if the process
is the embedded libfbembed.so process. For gbak to connect to the
file locally as a database under Superserver, it has to make a
connection through localhost and provide the -se[rvice_mgr]
argument. So, again, the fact that it appears your *has* created and
accessed a database suggests that gbak is using a client that a) is
old and b) is not libfbclient.so.

4) Furthermore, under Fb 2.0, using an Fb 2.0 client and the Fb 2.0
gbak, you should not be able to proceed with the gbak -REP command if
you have already attempted to restore the backup and have an existing
file of the name provided to gbak in the database argument. Under Fb
2.0, the -REP switch resolves immediately to -C[reate_database] and
should fail preemptorily if the named file exist. So here there are
at least 2 possibilities: you're not actually looking at a newly
restored database at all after your restore re-runs; or (once again)
gbak is using an old Classic libfbembed.so.

>Also tried the process using the backup/restore in IBExpert but that
>doesnt give the same detail of the errors.

That would be interesting to pursue, since IBExpert doesn't invoke
gbak at all. It uses a direct call to the Services API using the
full gamut of parameters for remote connection. And, of course,
there is no possibility that an IBExpert session on Windows could
become entangled in a conflict with a leftover copy of libfbembed.so
on the server.

I suggest the following:

1) Delete or rename the database file you have already created with
your previous attempt.

2) cd to the /opt/firebird/bin directory of your Fb 2.0 Superserver ....

3) ... then try to perform an unfettered restore using the proper
syntax for Superserver.

We'll assume you have a system user called 'dbadmin' and the backup
file is in your home directory in a folder called 'incoming' that the
'firebird' system user has read permissions to. And you want to
create the database in a folder called /fbdata that is owned by the
'firebird' user.

To eliminate possible problems with /temp, configure an explicit
location (existing, and owned and operated by the 'firebird' user)
for Firebird's sort files in firebird.conf. Make sure you have
plenty of disk space available.

Restart fbserver after you have saved firebird.conf.

Then, all in one command, but broken up here for clarity:

./gbak -c -v -user XXX -pas xxx
-se localhost:service_mgr
/home/dbadmin/incoming/source.fbk
/fbdata/destin.fdb

./heLen