RE: [Firebird-devel] damn gbak Win32 error

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

> -----Original Message-----
> From: fir...@li...
> [mailto:fir...@li...]On Behalf Of Mike
> Nordell
>
> > 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.
>
> This is weird. I get the same error using a short filename.

This is more weird and it's not a joke, because I traced the engine (see my
letter about GetShortPathName) and I found that while the fn is between 8.3
boundaries, a function named
init() in jrd does:

/* Check to see if the database is already actively attached */

for (dbb = databases; dbb; dbb = dbb->dbb_next)
    if (!(dbb->dbb_flags & (DBB_bugcheck | DBB_not_in_use)) &&
#ifndef SUPERSERVER
        !(dbb->dbb_ast_flags & DBB_shutdown && dbb->dbb_ast_flags &
DBB_shutdown_locks) &&
#endif
	(string = dbb->dbb_filename) &&
	!strcmp (string->str_data, expanded_filename))
	return (attach_flag) ? dbb : NULL;

With short names, the strcmp works. With long names, it doesn't work,
because GetShortPathName can't be resolved before the file has been written
after CreateFile call (or at least it has been noticed by NTFS, where is
this limitation documented???) so the dbb carries the long name, whereas the
new attachment (that could resolve the short fn because the gdb file was
already visible) carries the short name. Indeed, it works for me in local
mode with short names. This is why I was proposing at this point to attempt
a last-resort GetShortPathName call with string->str_data as input and
compare that output (if valid) with expanded_filename.


> Strange. Why should it try to open those DLLs (defined in
> images[] in why.c)
> when using LFN, but not when using 8.3??? My guess is that its a
> buffer that
> is too small. I'll try to find it.

Maybe because the why sees that the subsystem returned a problem, hence it
tries the equivalent function in the next subsystem available, and those
functions are registered. Ann, any idea what those GDS_A, GDS_B, GDS_C and
GDS_D mean? Are they debris of an old gateway to another engine?


> What would happen if we detached just before the re-attachment in its
> attempt to set these two flags?

I think that I would be fine and maybe we could collapse the two attach
calls that are in that place in one that sets both required flags.


> Aren't these issues unrelated? I get bad results from restoring a
> file with
> a short name. Using a file with a long (path-) name I can't even connect
> using isql.

Don't know. You are getting worse results than me and I don't have idea why.
(Why, why, I mean the word, not the y-valve.) My debugging suggest that your
case is impossible, but well, I'm still on NT4, your mileage may vary.


> This is a hairy area, l10n. I think the "best" we can do if we
> really decide
> to tackle this problem is to use platform specific locale-specific code.
> I.e. for Win32 we'd use CompareString (Win32 API). Another way to
> fix it is
> by simply doing a FindFirstFile() call and use what the OS tells us. :-)

The SDK suggests using FindFirstFile in cases where GetLongPathName wouldn't
work, don't know if the rule applies in reverse. After all, FindFirstFile
should do the dirty work, provided that we store the correct file name, of
course.
:-)
Seriously speaking, I'm tempted to change the code, but Murphy says I will
mangle another place in worse ways.


> Btw, this isn't a problem for the platforms that have case-sensitive
> filenames, is it?

I think that we at Win32 are the only victims.
First, no other platform uses IPC. (I'm not completely sure how IPC changes
the landscape, since using TCP for the target GDB causes the same problem.)
Second, no other platform has restricted access to the GDB in exclusive
mode, unless you...
Finally and more obvious, the engine doesn't need to care about uppercasing
in other platforms.

One of the problems is that isc_create_database calls ISC_expand_filename
before the file is ever created. I think I overcame the hurdle finally.

C.