Subject | Re: [ib-support] Re: --* Please Help*--- Database corruption and cannot backup & restore |
---|---|
Author | Ivan Prenosil |
Post date | 2001-08-08T18:10:35Z |
I am confused by this discussion about missing backslash in connection string causing problems.
Are you people talking about your experience or just know it from hearsay ?
Here is how I see it:
Fully specified file on Windows consists of
-drive letter
-absolute path
-file name
File specification can be incomplete, because drive letter can be omitted,
path can be omitted, or path can be relative.
In this case Windows will supply missing parts;
instead of talking about details, here are some examples:
when you specify
C:db.gdb
Windows will usually use
C:\windows\system32\db.gdb
when you specify
D:ibdir\db.gdb
Windows will usually use
D:\ibdir\db.gdb
when you specify
\db.gdb
Windows will usually use
C:\db.gdb
Interbase needs to detect whether you require connection to new
database, or to database that is already opened. To do so,
it must compare file names (because in Windows there is not any numeric
identification of file like on Unix).
So, strings like
D:ibdir\db.gdb
and
D:\ibdir\db.gdb
are different and caused problems on IB4, IB5.
But what if IB completes "wrong" path itself (instead of waiting
for Windows to do so) and convert it to fully specified file,
and then uses this full path to compare connection strings?
There is Windows API function GetFullPathName() that can be used
to do it. And scan of IB-source directory revealed that GetFullPathName()
is indeed used in "isc_file.c" file.
A quick test confirmed that connection strings like
D:ibdir\db.gdb
or
D:\abc\..\ibdir\db.gdb
will cause problems with IB5, but _not_ with IB6!
====
Problems can probably be caused by double-named files when using
symbolic links (or how is it called on NT),
but I admit that I know nothing about them.
====
I do not like much the idea of opening db file in exclusive mode.
One of the reasons is that one "bad" user can block access to the database
to all "good" users if you connect with wrong string first.
====
Ivan
prenosil@...
http://www.volny.cz/iprenosil/interbase
Are you people talking about your experience or just know it from hearsay ?
Here is how I see it:
Fully specified file on Windows consists of
-drive letter
-absolute path
-file name
File specification can be incomplete, because drive letter can be omitted,
path can be omitted, or path can be relative.
In this case Windows will supply missing parts;
instead of talking about details, here are some examples:
when you specify
C:db.gdb
Windows will usually use
C:\windows\system32\db.gdb
when you specify
D:ibdir\db.gdb
Windows will usually use
D:\ibdir\db.gdb
when you specify
\db.gdb
Windows will usually use
C:\db.gdb
Interbase needs to detect whether you require connection to new
database, or to database that is already opened. To do so,
it must compare file names (because in Windows there is not any numeric
identification of file like on Unix).
So, strings like
D:ibdir\db.gdb
and
D:\ibdir\db.gdb
are different and caused problems on IB4, IB5.
But what if IB completes "wrong" path itself (instead of waiting
for Windows to do so) and convert it to fully specified file,
and then uses this full path to compare connection strings?
There is Windows API function GetFullPathName() that can be used
to do it. And scan of IB-source directory revealed that GetFullPathName()
is indeed used in "isc_file.c" file.
A quick test confirmed that connection strings like
D:ibdir\db.gdb
or
D:\abc\..\ibdir\db.gdb
will cause problems with IB5, but _not_ with IB6!
====
Problems can probably be caused by double-named files when using
symbolic links (or how is it called on NT),
but I admit that I know nothing about them.
====
I do not like much the idea of opening db file in exclusive mode.
One of the reasons is that one "bad" user can block access to the database
to all "good" users if you connect with wrong string first.
====
Ivan
prenosil@...
http://www.volny.cz/iprenosil/interbase