Artur Anjos wrote:

>Also, we have an 'obscure parameter' (obscure=not documented) in
>gfix, -kill, that will make the database stop using the shadow. I'm really a
>newbie in Fb source code, but it seems to me that the kill implementation is
>just 'stop it, I don't care about nothing'.
>
>

I don't like undocumented features. The originally philosphy was 100%
open interface. If a
feature was important enough to implement, it was important enough to
document. This kept
us honest. Another way to put the same concept is "no back doors." If
the Borland crowd
had observed this, there wouldn't have been an intergalactic
politically/correct security fiasco.

>(Please someone correct me here, but looking at the source it seems to me
>that this operation just deletes the shadow reference in internal tables,
>and change some flags to inform the engine to stop using it)
>
>AFAIU, some work on this "kill" method will be enough to give us a workable
>backup file 'on the fly'.
>
>

Please don't do it this way. If you want a clone database feature, make
a clone database feature.
It can use the same code internally, but if the function is different,
give it its own command.

>[
>But Nickolay's propose method bring us a way not just to do to a very fast
>snapshot of the database: it will open a way for incremental backups.
>]
>
>

I've never been a fan of incremental for databases. For an OS backing
up files -- sure. You
find the most recent version of a file to be recovered, any everybody's
happy. If you have a
complex set of files, you have a mess. But trying to do the same thing
with a single file is
asking for disaster, particularly since recovery only takes place after
a disaster, everyone
is upset, and the ability to perform complex tasks is at its lowest
point. Making disaster
recovery the easiest part of the total system is good human engineering.

Dedicating a disk ($50) in a removable tray ($15) is very cheap, very
reliable, and very
difficult to screw up.

>IDE hard disks prices are really atractive. Not just replacing tapes, but
>almost replacing the cheap cd. :-)
>

And virtually the only way to send large files through the mail.