Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GFIX -shut -force leaves lock on a database file thus preventing a subsequent restore [CORE97] #421

Closed
firebird-issue-importer opened this issue Jun 21, 2004 · 19 comments

Comments

@firebird-issue-importer

Submitted by: nealo (nealo)

Is duplicated by CORE1611

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 1.5.0.4306 (super server) on winXP sp1

Full description (mostly) as posted in
mailto:firebird-support@yahoogroups.com:

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 http://firebird.sourceforge.net 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
the OWNER
- 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.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

Commented by: Alice F. Bird (firebirds)

Date: 2004-11-19 07:39
Sender: dimitr
Logged In: YES
user_id=61270

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.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

Commented by: Alice F. Bird (firebirds)

Date: 2004-11-18 21:32
Sender: skidder
Logged In: YES
user_id=495356

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?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

Commented by: Alice F. Bird (firebirds)

Date: 2004-11-17 20:36
Sender: dimitr
Logged In: YES
user_id=61270

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

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

Commented by: Alice F. Bird (firebirds)

Date: 2004-08-05 11:35
Sender: makowski
Logged In: YES
user_id=483965

I confirm this bug with the 1.5.1 version too

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 18, 2006

Modified by: @dyemanov

Fix Version: 3.0 [ 10048 ]

SF_ID: 976756 =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 19, 2006

Modified by: Alice F. Bird (firebirds)

description: 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 1.5.0.4306 (super server) on winXP sp1

Full description (mostly) as posted in
mailto:firebird-support@yahoogroups.com:

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 http://firebird.sourceforge.net 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
the OWNER
- 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.

=>

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 1.5.0.4306 (super server) on winXP sp1

Full description (mostly) as posted in
mailto:firebird-support@yahoogroups.com:

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 http://firebird.sourceforge.net 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
the OWNER
- 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.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 6, 2006

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 16, 2006

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 16, 2007

Modified by: @dyemanov

Target: 2.5.0 [ 10221 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

Fix Version: 3.0.0 [ 10048 ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 22, 2007

Modified by: @dyemanov

Link: This issue is duplicated by CORE1611 [ CORE1611 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 28, 2008

Modified by: @pcisar

Workflow: jira [ 10121 ] => Firebird [ 14322 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Feb 23, 2008

Modified by: @dyemanov

status: Open [ 1 ] => Open [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

Fix Version: 2.5 Alpha 1 [ 10224 ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 10, 2008

Modified by: @dyemanov

Fix Version: 3.0 Initial [ 10301 ]

Fix Version: 2.5 Beta 1 [ 10251 ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 29, 2009

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 3.0 Initial [ 10301 ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 24, 2009

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 RC1 [ 10362 ]

Fix Version: 3.0 Alpha 1 [ 10331 ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 24, 2009

Modified by: @dyemanov

summary: GFIX -force leaves lock on database file - can't restore => GFIX -force leaves lock on a database file thus preventing a subsequent restore

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 24, 2009

Modified by: @dyemanov

summary: GFIX -force leaves lock on a database file thus preventing a subsequent restore => GFIX -shut -force leaves lock on a database file thus preventing a subsequent restore

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 12, 2009

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 19, 2016

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants