Alexey Kovjazin wrote:

> Hello, Pavel!
>
> This is a well-known ambush in Linux + Firebird, related with fact that
> server does not release database until last user disconnected and, in the
> same time, Linux allows you to delete and "replace" file.
> I am not sure what exact versions of FB and Linux suffer from this but I
> suppose that all.

Ah! This is because FB connects to the db file via a "reference" in the
same manner as the directory listing.

do a ls -l and look at the ref count, one for the filesystem (dir
listing entry) and one extra for each FB server open File handle.

It is a feature of linux,SYS5,BSD,AEGIS,... based systems and used often
as a way to provide processes with "temp" filesystem space by
creating a filesystem file, opening it (usually read+write) then
unlinking it from the filesystem.

When the db file is "restored", the original DB file is "removed" and
"replaced" with a new file.

At removal time the filesystem reference is removed but the FB server
still has it open (a reference) and therefore is still accessing the now
deleted (from filesystem) DB file.

At restore, a new DB file is created which is NOT being accessed by the
server. Any changes will take place in the deleted from filesystem
db file and when the server is shut down the disk space used for the
now fully de ref'd original db file will be available for re-use.

This is identical to the problem when people try and truncate
apache log files by deletion/recreation. As apache (used to) keeps log
files open all the time, the disk space for the old files remains
"in use" until the server is stopped, at which point the disk space is
freed. A couple of df -k before and after server shutdown will
provide enough evidence of the old files being freed only when
server is shutdown.

I remember using the same "trick" on *nix systems in the 70's - so this
is not something new and wicked :-)

Jacqui