Issue Details (XML | Word | Printable)

Key: CORE-97
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: nealo
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

GFIX -shut -force leaves lock on a database file thus preventing a subsequent restore

Created: 21/Jun/04 12:00 AM   Updated: 19/Jan/16 05:24 AM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 2.5 RC1

Issue Links:

SF_ID: 976756
Target: 2.5.0
QA Status: No test

 Description  « Hide
SFID: 976756#
Submitted By: nealo

With GFIX -force, I cannot use GBAK to perform a
restore. Windows reports the DB file as 'in-use' until
all instances of the firebird clients (that were
connected when the -force was performed) are closed.

I'm using FB (super server) on winXP sp1

Full description (mostly) as posted in

The -force option for GFIX does not seem to work
correctly. As a result, I am not able to automate the
backup/restore process. I'm just following the
procedure outlined at and
posting it here first.

To reproduce the bug:

- use an FB client (I used IBAccess in my test) to
connect to a database using a user other than SYSDBA or
- from a command prompt:

gfix -user "SYSDBA" -password "masterkey" -shut -force
0 <database>

When GFIX completes, the database connection
established in IBAccess can no longer do anything
(expected), but when I try to perform a restore to the
database using GBAK

gbak -R -user "SYSDBA" -password "masterkey" <backup
file> <database>

I get:

gbak: ERROR: could not drop database <database>
(database might be in use)
gbak: Exiting before completion due to errors

If I then close IBAccess, the GBAK call succeeds.

gfix -force does prevent new connections and it does
prevent existing connections from doing anything. But
it seems that the existing connection still keeps a
grip on the database file.

So I can't reliably automate a database backup/restore.
End users have a bad habit of leaving the client
application open overnight.

I don't know if this is a bug with GFIX or with FBServer.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:32 AM
Date: 2004-11-19 07:39
Sender: dimitr
Logged In: YES

Nickolay, the reported issue is a by-design one. Shutdown
just was not designed to disconnect everyone. But with your
new shutdown modes I expected that either this behaviour is
changed (gfix -shut force disconnects everyone) or, if we
want to keep a legacy behaviour, an alternative modes are
available and some of them do force active attachments to
close. Since I don't remember exactly the new shutdown
modes, I hoped you could comment.

Alice F. Bird added a comment - 14/Jun/06 09:32 AM
Date: 2004-11-18 21:32
Sender: skidder
Logged In: YES

To the best of my memory while I fixed a bunch of issues
related to database shutdown I did nothing so far to address
this particular problem.

Dmitry, are you sure that the disappeared in Firebird 2.0?

Alice F. Bird added a comment - 14/Jun/06 09:32 AM
Date: 2004-11-17 20:36
Sender: dimitr
Logged In: YES

AFAIU, this is no longer an issue for v2.0, but I'd like
Nickolay to comment.

Alice F. Bird added a comment - 14/Jun/06 09:32 AM
Date: 2004-08-05 11:35
Sender: makowski
Logged In: YES

I confirm this bug with the 1.5.1 version too