At 09:20 PM 8/12/2005 +0000, you wrote:

>Using the IBOAdmin components to backup and restore databases, I
>sometimes get an error while restoring a backup (*.fbk) database.
>
>On linux: I/O error for file "/tmp/0"
>and on Windows XP Pro: I/O error for file "C:\Windows\System32\0"
>
>I'm running the superserver on linux (LI-V1.5.1.4481)
>and windows (WI-V1.5.2.4731).
>
>The error occurs both on remote and local systems and different
>databases. To rule out the backup process introducing the problem,
>I have tested both with and without clients attached to the databases

I doubt that. If your tests are running from your application or from the
IDE, it's very unlikely that you won't have at least one client attachment
alive unless you specifically coded and post-checked an explicit Disconnect.

>It seems like some sort of timing problem... I've already inserted
>a 2 second hold-off time bewteen backup and restore procedures and can
>increase this value, but I'd like to know why the error occurs before
>doing this.
>
>One final piece of info: the backup and restore procedures run from
>whithin a thread in the delphi application.
>
>Any thoughts are welcome

Too much is unsaid here.

Are you really backing up a database and then immediately restoring it
without testing whether you have a restorable backup?

I/o errors from gbak (which, be assured, is what you are using through the
service components, despite your misleading statement in your cross-post to
the support list...) are literally file i/o errors. Like any other failed
attempt to access a file, it will be caused by one or more of the following:

1. the file isn't where you said it was. Usual reason: you didn't supply
the full path to the file; or you supplied an invalid path. For
restoring, gbak is interested in either two or three files, depending on
whether you set the -R switch (for Replace Database) or the -C switch (for
Create Database).

*** The -R switch needs file access because, before it can begin restoring,
it has to delete the old database file and create a new, empty file of the
same name.
*** The -C switch needs file access because it has to create a new database
file.
*** And of course the backup file (your fbk file, which is not a database
at all, just a file).

Relative paths won't work. If you didn't supply full file specs, each of
the servers has default places where it will go looking. That looks like
what's happening here (for which I think you need to be grateful....)

2. On Linux, the service_manager (the firebird user) has to have the
appropriate filesystem permissions to the files and *also* execute
permission for the directories where it has to do anything. On Windows,
the service_manager will have totally destructive rights if Firebird is
running as a service and you haven't done anything since installation to
change that; or the rights of the user that started the server, if running
as an application.

3. If you use the ReplaceDatabase switch (not recommended, except when you
don't care whether your database survives or not), gbak won't be able to
delete the database file if there is a connection to it. You can't delete
files that are open.

Also note that a gbak restore is not an atomic operation. Even if the
restore falls over, anything that happened before the new database file was
created will not be undone - specifically, if gbak deletes your database
and then can't find the backup file, it's all over. The database file is
gone. You'd better hope that, when you finally give the right info to
gbak, you actually have a restorable backup.

gbak -R is a fully-loaded high-velocity firearm pointed directly at your foot.

Helen