RE: [Firebird-devel] damn gbak Win32 error

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

> -----Original Message-----
> From: fir...@li...
> [mailto:fir...@li...]On Behalf Of
> Dmitry Kuzmenko
> Sent: Mi=E9rcoles 24 de Octubre de 2001 13:02
>
> Some person have done bad things in code near build 493.
>
> Error is when gbak trying to work with long filenames.
> Changes were made in SERVER code,

How do you know that, by looking at the log or at SF tree?


> i.e. ibserver.exe
> gives
>
> c:\intrbase\bin\gbak.exe -r employee.gbk ..\INTERBASE\examples\v5\e=
mploy
> ee.gdb -user sysdba -pass masterke
> gbak:     restoring index RDB$FOREIGN26
> gbak: finishing, closing, and going home
> gbak: ERROR: I/O error for file
> "D:\IB6COMP\INTERBASE\EXAMPLES\V5\EMPLOYEE.GDB"
> gbak: ERROR:     Error while trying to open file
> gbak: ERROR:     unknown Win32 error 32
> gbak: Exiting before completion due to errors
>
> during compilation process.

It seems reproducible. Long paths will wrap:

H:\temp>md
dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirname1\andt=
hisisan
otherlongdirname
and then
H:\ibdev\fbbuild\interbase\ib_debug\bin>ibserver -a
(This is the latest version I have from last night.)

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -b h:/temp/atlas.gdb
H:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\atlas.gbk

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\atlas.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\atlasnew.gdb

Second try, now with employee:

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\ibdev\fbbuild\interbase\example5\employee.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\emplonew.gdb

No problems. However, I just change the destination file name and the
history turns gory:

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\ibdev\fbbuild\interbase\example5\employee.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\employee_new.gdb
gbak: ERROR: I/O error for file
"H:\TEMP\DIR1\DIR2\DIR3\DIR4\DIR5\DIR6\DIR7\DIR8\DIR9\THISISALONGDIRN=
AME1\AN
DTHISISANOTHERLONGDIRNAME\EMPLOY
gbak: ERROR:     Error while trying to open file
gbak: ERROR:     unknown Win32 error 32
gbak: Exiting before completion due to errors

So the long filename and not the directory hierarchy seems to be the
problem. Look at "employ", what happened there? The file name is trun=
cated.

Then I retry exactly the same command:
H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\ibdev\fbbuild\interbase\example5\employee.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\employee_new.gdb
gbak: ERROR: database
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\employee_new.gdb already exists.  To replace=
 it,
use the -R switch
gbak: Exiting before completion due to errors

Now, this is confusing. The first attempt to restore *apparently* fai=
led but
when I retry it, the gdb has been created. Did I get a completely res=
tored
db? I think that it depends where the generic error "exiting before
completion" was produced. Gbak was able to locate the restored db and=
 gave
it the right name. Further, when I go to the nested dir hierarchy, th=
e name
of the gdb is effectively employee_new.gdb, not employ. Trying isql:

H:\ibdev\fbbuild\interbase\ib_debug\bin>isql
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\employee_new.gdb
Database:
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\employee_new.gdb
SQL> show tables;
       COUNTRY                                CUSTOMER
       DEPARTMENT                             EMPLOYEE
       EMPLOYEE_PROJECT                       JOB
       PHONE_LIST                             PROJECT
       PROJ_DEPT_BUDGET                       SALARY_HISTORY
       SALES
SQL> select * from country;

COUNTRY         CURRENCY
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

USA             Dollar
England         Pound
[snip]

The db seems to work as expected. Checking structure:

H:\ibdev\fbbuild\interbase\ib_debug\bin>gfix -v -f
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\employee_new.gdb

There's nothing reported as bad in the new db. I didn't trace gbak to=
 find
the point where it fails.


> If I try to run prev ibserver.exe, for example 338, 441 or 493,
> I'll get another kind of error, saying that RDB$PRIMARY24
> for table SALES (intlemp.gdb) have NULLs, which is INCORRECT
> (no nulls at all).

I never have gotten this error while building the engine. However, le=
t me
say that I reported this bug to Borland while testing kinobi (IB6 bet=
a) back
in Oct-1999 under NDA, when upgrading from a valid IB4 db to IB6 beta=
. To my
knowledge, Borland never fixed the issue, so it's possible that it's =
still
there. Just trying with long file name:

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\ibdev\fbbuild\interbase\example5\intlemp.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\intlemp_new.gdb
gbak: ERROR: I/O error for file
"H:\TEMP\DIR1\DIR2\DIR3\DIR4\DIR5\DIR6\DIR7\DIR8\DIR9\THISISALONGDIRN=
AME1\AN
DTHISISANOTHERLONGDIRNAME\INTLEM
gbak: ERROR:     Error while trying to open file
gbak: ERROR:     unknown Win32 error 32
gbak: Exiting before completion due to errors

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\ibdev\fbbuild\interbase\example5\intlemp.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\intlemp_new.gdb
gbak: ERROR: database
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\intlemp_new.gdb already exists.  To replace =
it, use
the -R switch
gbak: Exiting before completion due to errors

Again, the thing was created with the right name at the first attempt=
s,
regardless of the premature termination and annoying error message. D=
oes the
engine try to open the gdb a second time before the restore finishes =
or do
the engine and gbak clash on the gdb? To be clear on the name:

H:\ibdev\fbbuild\interbase\ib_debug\bin>gbak -c
H:\ibdev\fbbuild\interbase\example5\intlemp.gbk
h:\temp\dir1\dir2\dir3\dir4\dir5\dir6\dir7\dir8\dir9\thisisalongdirna=
me1\and
thisisanotherlongdirname\12345678901.gdb
gbak: ERROR: I/O error for file
"H:\TEMP\DIR1\DIR2\DIR3\DIR4\DIR5\DIR6\DIR7\DIR8\DIR9\THISISALONGDIRN=
AME1\AN
DTHISISANOTHERLONGDIRNAME\123456
gbak: ERROR:     Error while trying to open file
gbak: ERROR:     unknown Win32 error 32
gbak: Exiting before completion due to errors

Always six characters? Is this related to long to short names convers=
ion?
Typical short form of long names is the six first characters plus "~"=
 plus a
number. Again, the original long file name gdb was created and it doe=
sn't
have errors.


> This situation breaks compilation on Win32, and not only.
> I've tried to compile build 514 without examples, and moved
> new binaries to the root interbase dir (i.e. to compile build 514
> running ibserver and gbak same build - 514).
> Error is not gone.

Well, if you got it near build 500, in 514 there's no reason to think=
 it's
gone if there's no comment at all in SF commits.


> I don't know what to say, if somebody can break current functionali=
ty
> and does not care about consequences. This is bad, very bad.

People that work in the engine usually make use of the engine. If the=
 person
that supposedly caused the problem didn't fix it, it may because the =
problem
wasn't noticed. Basically, if someone does that mistake, the own pers=
on will
suffer the mistake, too, so saying "doesn't care" is a supposition yo=
urs.
Please, be more responsible in your accusations. If what you want is =
simply
to scold people, you will cause a flame war. Is this what you want? I=
t's
easier to criticize than to cooperate.


> I suggest every person who make changes to repeat compilation
> process with currently compiled build. And only THAN post changes
> to FB cvs.

This seems a valid and sensible suggestion.


> p.s. people, are we going to release? Or we will wait until Borland
> will release 6.5 and every user will move to it?

Going to release with pending issues like this? Are you kidding?


> If nobody cares, and want cash or profit for his work, what we
> are doing here?

If you simply want to offend, I could tell you enough things to offen=
d you.
If you feel that you are doing a great contribution with your asserti=
ons,
first the people that supposedly want money (according to you) could =
ask you
what's your cooperation on this, with or without money. Do you really=
 want
to start a fight?


> Right now one russian developer have made 5 times much new features
> to the engine, making FB work faster and customisable. He's doing
> this when sourceforge.net/projects/firebird starting to produce
> new bugs. Is this right? I think no.

It's easy to say, for example "I have a friend that implemented full =
SQL99
comformance, fixed all known bugs and created a new security model" w=
ithout
any proof. Dmitry, if this person is doing such a work as you say and=
 "you
know" about this work so well without any attempt to validate your cl=
aim, I
can assume that the changes are hiddden from the general audience aga=
inst
the IPL. In this case:
- Does he know that he's violating the license by not making his chan=
ges
available?
- If there's no place where to see or test his compiled changes, then=
 we
only have to trust you, but your assertion seems more a troll than ot=
her
thing.
- If he's so quick and wonderful to make changes, is there any reason=
 he
doesn't want to contact Borland or firebird? Is he ashamed of his wor=
k? Or
does he enjoy violating the license? Or is he doing those changes onl=
y for
money for a private company that doesn't care to violate the IPL and =
retain
the changes privately?
- In the case he's violating the license and you know the sources and=
 have
tried them without disclosing the location, you are violating the lic=
ense,
too.

Otherwise, where are those changes or a binary to test it? And apart =
=66rom
sending diatribes against our work here, what else are you doing? Hav=
e you
tried to contact that person if he wants to work with anybody else at=
 least?

(I know my letter is not funny, but what did you expect after your or=
iginal
posting? It highlighted a problem, but you crossed the line with your
accusations.)

I hope that nobody is using these interim builds in production. Only =
an
insane would do. The problem is that anybody can see latest sources a=
nd try
to compile them.

C.