RE: [Firebird-devel] damn gbak Win32 error

[Claudio V. C. <cv...@us...>]

> -----Original Message-----
> From: fir...@li...
> [mailto:fir...@li...]On Behalf Of Mik=
e
> Nordell
> Sent: Jueves 25 de Octubre de 2001 5:34
>
> Also note that error 32 is sharing violation. It probably has somet=
hing to
> do with my "lockdown" of DB files, and possibly suggests there
> might be a DB
> file that isn't really closed when an error occurs.

Well, then it's your pet bug. <g>
See it in action with the latest sources:

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c h:/temp/bp.gbk
h:/temp/bp_long_name.gdb
gbak: ERROR: I/O error for file "H:\TEMP\BP_LONG_NAME.GDB"
gbak: ERROR:     Error while trying to open file
gbak: ERROR:     The process cannot access the file because
it is being used by another process.

gbak: Exiting before completion due to errors

At least the name is no longer truncated in the error message like th=
e
example I posted previously.
:-)

In other words: I (the engine) cannot access the gdb file because som=
ebody
(myself) has it opened already. How about biting its own tail? Notice=
 that
the gdb is created anyway. If I change the target name to 8.3 format =
(ex
bp2.gdb) I do not get any problem.

I hope this info will trigger some idea on you, Mike: when using the =
short
file name, filemon shows a normal bunch of calls. However, when using=
 the
long name, those mysterious entries appear. I tried to trim them a bi=
t:

MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_A=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_A=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_A.DLL=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_A.DLL=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_B=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_B=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_B.DLL=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_B.DLL=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_C=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_C=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_C.DLL=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_C.DLL=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_D=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_D=09FILE NOT FOUND
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\UDF\GDS_D.DLL=09FILE NOT FOUND
MJ_CLEANUP=09F: DASD=09SUCCESS
 =09F: DASD=09SUCCESS
MJ_CREATE=09F:\BD\BORLAND\INTERBASE\intl\GDS_D.DLL=09FILE NOT FOUND
REATE=09F:\BD\BORLAND\INTERBASE\interbase.msg=09SUCCESS
REATE=09F:\BD\BORLAND\INTERBASE\interbase.msg=09SUCCESS
[snip]

After that point, a lot of accesses to the MSG file happen, while loo=
king
for the error message to display. I don't have any idea why those
GDS_[a|b|c|d]
appear in this case, but they only appear when using a long gdb file =
name to
restore. Notice those lines in the Y-valve:

jrd\why.c:500:#define GDS_A_PATH        "lib/gds_1"
jrd\why.c:510:#define GDS_A_PATH        "GDSAA"
jrd\why.c:520:#ifndef GDS_A_PATH
jrd\why.c:521:#define GDS_A_PATH        "GDS_A"
jrd\why.c:600:    "GDS_A", GDS_A_PATH,

jrd\why.c:501:#define GDS_B_PATH        "lib/gds_2"
jrd\why.c:511:#define GDS_B_PATH        "GDSBB"
jrd\why.c:522:#define GDS_B_PATH        "GDS_B"
jrd\why.c:601:    "GDS_B", GDS_B_PATH,

jrd\why.c:502:#define GDS_C_PATH        "lib/gds_3"
jrd\why.c:512:#define GDS_C_PATH        "GDSCC"
jrd\why.c:523:#define GDS_C_PATH        "GDS_C"
jrd\why.c:602:    "GDS_C", GDS_C_PATH,

jrd\why.c:503:#define GDS_D_PATH        "lib/gds_4"
jrd\why.c:513:#define GDS_D_PATH        "GDSDD"
jrd\why.c:524:#define GDS_D_PATH        "GDS_D"
jrd\why.c:603:    "GDS_D", GDS_D_PATH

Ann, can you explain those names and their intended meaning, please? =
It
seems as if the y-valve was causing some reentrance problem or lookin=
g
[unexpectly] at some special files.

Apart from the funny trace shown above (thay may be totally harmless)=
, I
think that RESTORE_restore() is the main culprit:

BURP_verbose (88, NULL_PTR, NULL_PTR, NULL_PTR, NULL_PTR, NULL_PTR);
/* msg 88 finishing, closing, and going home */

MVOL_fini_read (&cumul_count_kb);

/* attach database again to put it online */
Now it builds the dpb's, restores forced writes' settings and does
if (isc_attach_database (tdgbl->status_vector, 0, GDS_VAL(database_na=
me),
=09=09=09  (isc_db_handle*)GDS_REF( db_handle), l, dpb))
    general_on_error();
if (isc_detach_database (tdgbl->status_vector,
(isc_db_handle*)GDS_REF(db_handle)))
    general_on_error();
FINISH;
show a message is indices couldn't be activated
restores read only settings
mark operation as successful and return to BURP_gbak

The call to isc_attach_database() fails. So, the db was fully created
already. It seems as it the engine considers gbak already attached to=
 the
gdb it's creating, because FINISH is expanded to a "detach" call plus=
 error
checking. So what do we miss:
- forced writes aren't restored
- read only isn't restored

Is there a way to fix gbak? Otherwise, we are going to need an API en=
try
point to restore forced writes and R/O settings. It seems as if the y=
-valve
is unable to determine that there's a connection already to the same =
db. In
this case, the failing code seems to be in
IPI_attach_database/check_response, that's part of the IPC server use=
d for
NT. Is the IPC fooled by the long name for the memory mapped file?

In previous FB builds, two isql sessions could do that:
H:\ibdev\fbbuild\interbase\ib_debug\bin>isql h:/temp/bp_long_name2.gd=
b
Double clicking the FB's icon in the tray shows two attachments and o=
ne
database.
Now, repeating the experience with the poor bird and latest build:
- first isql session succeeds.
- second isql session hangs, isql never shows the SQL> prompt, it onl=
y shows
the db name it's connecting to.
- I try close the first isql session. Ctrl-Z or Ctrl-C has no effect.=
 I have
to use Ctrl-Break. Same on second isql session.
- Both consoles have returned to the command prompt outside isql. How=
ever, I
right click the fb icon in the tray and select shutdown to no avail: =
task
manager shows it's still running. Ironically, the tool tip is alive (=
in its
own thread) but right clicking has no effect. No menu is shown. Only =
task
manager can kill FB.

After this test, I'm not sure why check_response() fails with long fi=
lenames
but gets the right information with short filenames, when used from g=
bak.

Also, inside jrd/isc_file.c:ISC_expand_filename() we find

/* Filenames are case insensitive on NT.  If filenames are
 * typed in mixed cases, strcmp () used in various places
 * results in incorrect behavior.
 */

for (length =3D 0; length < file_length; length++)
    expanded_name [length] =3D UPPER7 (expanded_name [length]);

Can anybody theorize what happens when this code faces unicode file n=
ames or
an eastern NT version? As we know, UPPER7 only cares about ASCII uppe=
rcase.

C.
---------
Claudio Valderrama C.
Ingeniero en Inform=E1tica - Consultor independiente
http://www.cvalde.com - http://www.firebirdSQL.org