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-automations opened this issue Jun 21, 2004 · 19 comments

Comments

@firebird-automations
Copy link
Collaborator

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-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 [ 10048 ]

SF_ID: 976756 =>

@firebird-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Target: 2.5.0 [ 10221 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

Fix Version: 3.0.0 [ 10048 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE1611 [ CORE1611 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

Fix Version: 2.5 Beta 1 [ 10251 ]

Fix Version: 2.5 Alpha 1 [ 10224 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Initial [ 10301 ]

Fix Version: 2.5 Beta 1 [ 10251 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 3.0 Initial [ 10301 ] =>

@firebird-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

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