Alexey Kovjazin wrote:

> Hello, Jacqui!
>
>
>>It looks like FB server (super on my MDK box) does not keep an open
>>handle to the db file for any noticable time.
> Thanks for clear explanation.
> I think it should be added to FAQ somewhere.

I tried running a script (tight loop) watching the
ref count while I committed a transaction using Marathon
but saw no change. As the script was not compiled code
it is possible that the write occurred between
stat()s (in my script loop.

This linux box is 2.4Ghz and idle at the mo so I could
reasonably assume that the write occurred between stat()s
and the disk would be mostly idle.

One possibility (debug only!( would be to stat the file
handle before and after (reopened) the write and if the
inode has changed, report that a transaction *may* have
been lost as the database was replaced during a write.

The C code for this is pretty noddy, but my free time
is currently non existent :-(

If anyone plans to investigate I would recommend
trying a standalone test case rather than adding
one off debugging to FB server code...

I include a rough code template - I expect someone
will correct any mistakes I have made :-)

process1:
create a file
loop forever
open file (append mode)
stat file and save inode
lseek file
write some bytes sprintf(time) or similar
fflush() - see man fclose
close file

open file
stat file and get inode
close file
compare inodes
if different write to stderr.
end loop

process2:
at command line (repeat)
cp file.bak file
-- this should change the inode of file.

Jacqui