Re: [Firebird-devel] damn gbak Win32 error

[Mike N. <ta...@al...>]

Claudio Valderrama C. wrote:
> On Behalf Of Mike Nordell
>
>> Also note that error 32 is sharing violation. It probably has something
to
>> do with my "lockdown" of DB files,
[...]
>
>Well, then it's your pet bug. <g>

Thank you kindly! :-)

> In other words: I (the engine) cannot access the gdb file because
> somebody (myself) has it opened already. How about biting its own tail?

Yes, it assumes it can isc_attach_database() to a database it already has
open.

> 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.

> 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 bit:
[...]

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.

> Apart from the funny trace shown above (thay may be totally harmless), I
> think that RESTORE_restore() is the main culprit:
[...]
> 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,

It is. burp.c, open_files() has already called isc_attach_database() to the
same DB file.

> 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?

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

[...]
> Is the IPC fooled by the long name for the memory mapped file?

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.

[...]
>
> Also, inside jrd/isc_file.c:ISC_expand_filename() we find
[...]
>for (length = 0; length < file_length; length++)
>    expanded_name [length] = UPPER7 (expanded_name [length]);
>
>Can anybody theorize what happens when this code faces unicode file
> names or an eastern NT version? As we know, UPPER7 only cares
> about ASCII uppercase.

It will fail. UPPER7 is a plain binary thingie (only works for ASCII
charset).

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. :-)

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

/Mike - off to debug some code...