"Paul Reeves" <paul@...> wrote in message
news:3C87311F.866903B8@......

> Nando Dessena wrote:
> >
> > gbak -b -v c:\temp\mygdb.gdb c:\temp\1.gbk 10m c:\temp\2.gbk
> > gbak: ERROR: free disk space exhausted
> > gbak: Exiting before completion due to errors
> > gbak: ERROR: cannot disconnect database with open transactions (1
> > active)
> >
> > Is there a (known) bug or something I am missing?
>
> The more important one - gbak: ERROR: free disk space exhausted - has
> only just come to our (or at least my) attention. It looks as if gbak
> has forgotten how to work with multiple files. The error is triggered
> when file one is full.

Hmm, it's not a surprise.
I think you could reproduce it with a tiny db and a command like this:
gbak -b -v group.gdb group1 5k group2

Since the backup of an almost empty db is near 7K, you should see the same
problem.

Unfortunately, the error message that gbak reports is generic. Looking at it
in the Win32 help files, it's:
998 Invalid access to memory location.

Bug reported, bug killed. Casting an unsigned number to a signed number has
never been a good idea, less even if the unsigned value doesn't fit in the
signed one, so the latter wraps towards negative values.
:-)

BTW, don't get surprised that the report says
10 bytes written
instead of
10240 bytes written,
for example.

We will do our best to keep secret the name of the developer that caused
this message, to protect that developer and his/her family.
:-)

Immoral ad: however, for a modest fee, I could reveal the person's name.
:-) :-) :-)

The problem happened when *unnamed* decided to track the size of the files
in the internal structures in KBs instead of bytes. To do that, the
developer simply divided the counted bytes by 1024. The error that *unnamed*
was trying to solve was that file sizes can go above 2^31 bytes and then the
counter would wrap. That problem is for real with large files.

Then I discovered that gbak says:
I backed up 40 bytes
when in fact it backup up 40KB. Ann told me to simply add three zeroes to
the message (to what I don't agree) but I remember that *unnamed* suggested
that I could change the data structure's member that tracks the size to an
int64, but I never did. The report is hamless, you should assume KB, not
bytes.
:-)

I've changed gbak to not crash due to buffer overflows in some cases, I
changed it to allow backing up generators with embedded blanks in names and
other issues, but until now, I didn't know that you could use K, M and G to
specify sizes without having to write long numbers. Thanks for the tip.
:-)

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing