Hi Colin,

AFAIK that's a correct behaviour for filehandling on Linux (Unix).

After an application has opened a file, the directory entry
of that file is (for that fileconnection) no more used and may
be changed (i.e. renamed, deleted, ...). The application continues
using the file (its data) via the file's I-node.
If you "remove" (or rename) the file, you only remove (rename) the
file's entry in the directory. The file itself (meaning the file's
data) is removed by the system only if noone is accessing the file
(you may see that if you "remove" the file, but the 'df' command shows
the same filesystem usage as before).

In your case it seems that there exists another connection to the
test database so the SS is accessing the database's datafile.
Because the SS has opened the connection, every access to that
database (via the SuperServer) accesses the old data.
Check, if you closed all DB connections to the test database before
deleting/replacing the database with the backup.

Better do the following steps
o create backup of the test database (maybe you'll need that)
o drop the test database
o recreate the test database using the productive backup

If the database is in use, you should not be able to drop the
database. Also a 'shutdown' of the database will not force the SS
using the database (so the database's datafile is in use anymore).


Roger

--- In firebird-support@yahoogroups.com, "reg_hill_labs"
<reg_hill_labs@...> wrote:

>
> Hi,
>
> I have come across a strange situation, which I haven't seen before.
> Might be due to my lack of understanding of Linux or Aliases?
>
> The situation occurred as follows:
>
> Running FB SS 1.5.3 on Suse 9.2.
> Have DatabaseAccess = None and have two Aliases setup, say DBLive and
> DBTest, pointing to say, /someplace/DBLive.fdb live and
> /someplace/DBTest.fdb file.
>
> I intended to replace the test file with the latest live.
>
> I shutdown the test db, renamed it (DBTest2.fdb), backed up the live
> DB and attempted to restore it to the old dbs location and filename.
> This caused an error message saying the file existed and to use 'C' to
> create or overwrite the DB (or some such error).
>
> I checked and the file did not exist (as I had renamed it). I moved
> DBTest2.fdb, deleted it to the trash, still no go, finally gave up,
> and named the db to restore to something else (say DBTest3.fdb)… It
> worked.
>
> The file system then let me rename DBTest3.fdb to DBTest.fdb… what was
> Firebird talking about I wondered?
>
> I then looked at some data in my new DBTest.fdb, and hello, it did not
> contain the data from 'DBLive.fdb' as I expected, but was in fact data
> from the old 'DBTest.fdb'… the one that I had renamed, moved and then
> deleted, and that the alias did NOT point to.
>
> I then restored from the trash and 'shift-deleted' the file… still, I
> could access this deleted file, I could read and write data to it…
> don't know where it was writing to, as I had physically deleted the

file.

>
> While accessing it, I renamed 'DBTest.fdb' and it let me, so for some
> reason the database server was accessing another db file somewhere (no
> idea where, remember, the alias is pointing to the correct file).
>
> I then kicked everyone off the other databases in use, shut down the
> server and restarted it, and finally the server was reading the
> correct file.
>
> I then tried renaming that file, thinking the system would say, hay,
> it is in use, you can't do that, but it didn't… it let me rename it…
>
> I am now confused… is this something to do with Linux, Windows does
> not seem to have the same behaviour, it locks the file...
>
> Sorry for the long description… any info appreciated.
>
> Regards
> Colin
>