I don't like this...we must fix

OK here is a failsafe idea what we to to 6.0. We make it create a random
32 or 64bit number (probably generated by 32 bit timedate+32bit random) to
indentify each rebuild of any database. That is something to make every
file named bob.gdb most likely unique. As in when I create a new database
or gbak and restore, I get a new 64 bit id in the new database.

Now when the server opens a file, it checks for same ID open, and if same
ID is present already then look at the pathless filename to confirm that
it is indeed the same file being requested. I know the file check part is
practically redundant, but should be there in case ID = 0 for both ...
(which should be the case if no ID is found for backward compatibility,
for instance if I open on old gdb with an older on disk structure). By the
way, in the case of the ID returning 0, it should use full path for the
second comparison as apposed to just the pathless filename check...see I
thought about that.

Now you can drink beer and type in bad paths while you code like mother
nature intended, or simple wake up in a different world and do human
things like vary the path. Of course if ID is 0, you are using an old
disk structure and its your own fault you did not gbak it and are still
subject to path variations :).


Randal

On Fri, 28 Jan 2000, Chris O'Rourke wrote:

> It is unfortunate that I did not push this topic back in July 1999. I sent
> my humble description and a test application that could reproduce anomalies,
> off list, to an Inprise rep (who shall remain nameless). Probably too busy
> to progress a solution or did not fully understand the implications of this
> problem. For whatever reason no progress has been made.
> For that I apologise to the list and the Interbase user community.
> I just don't have the luxury of investigating solutions for a third party
> product and that is why I passed it over to Inprise (At least I thought I
> had). As far as our clients were concerned the corruption problem was
> resolved. (No further corruptions since enforcing consistent connection path
> names via the application).
>
> This bug lays dormant until it "slashes out" at unsuspecting sites who quite
> innocently introduce a different database path name connection into their
> environment.
> This still may not be the cause of Chris Herble's database corruption at the
> start of this list entry but certainly is worth at least a FORMAL reply from
> Inprise on the topic or a bug report entry on the Inprise web site.
>
> Summary of information (as I know it):
> 1. the corruption problem did not exist in V4.2 Interbase
> (the mixed path names were already in use, for two years, on the clients
> site prior to upgrading from V4.2 to V5.1)
>
> 2. Problem is associated with
> a) servers resolution of REMOTE access as two local connections to the same
> database using different connection strings, eg. "D:\Testdb.gdb" and
> "D:Testdb.gdb" will not have problems. b) Moreover the problem does not
> occur with the following connect strings: "MYPC:D:\Testdb.gdb" and
> "D:Testdb.gdb". As soon as a host name is included on "D:Testdb.gdb" as in
> "MYPC:D:Testdb.gdb" then anomalies will result (Regardless of whether the
> connection is actually local or not, ie. "MYPC" is the same host as the
> server to which you are connecting.)
> c) a drive other than "C:" (system disk) must be used. ie. "C:Testdb.gdb"
> will fail as a connection string; you are forced to use "C:\Testdb.gdb" and
> therefore no problems can result.
> So my apologies to Chris as it is more then the missing '\' that is
> important in this recipe for disaster.
>
> Chris wrote:
> >>There are 2 possible solutions to this bug;
>
> >>1) Ibserver should reject connection strings of the form "d:test.gdb" as
> >>ambiguous.
>
> >>2) Ibserver should resolve "d:\test.gdb" == "d:test.gdb", and carry on
> with
> >>a single database connection.
>
> 1) V5.6 appears to already reject "c:test.gdb" as a connection path so
> perhaps the fix is easier than we could hope for.
> 2) If the server is trying to match database paths for my mind this is
> unnecessary.
> A suggested solution:
> a) On connecting the first session for the first database the server would
> (after determining it is a valid database) write a unique number (perhaps a
> GUID) into the database header and keep a list of these GUIDs internally.
> b) subsequent connections would first attempt a read of the database on the
> supplied path and read the GUID from the header. Given the file exists and
> the read was successful then:
> c) if the GUID is not in the current list then must be a new database and a
> new GUID is written to the database header for this new database
> - if a match is found then the database has already been attached and so
> request is for the matched database. (this should work since an attached
> database is accessed exclusively by the server)
> d) when a database is released (last connection is freed) then the GUID is
> dropped from the internal list. This list is also memory resident so a crash
> (heaven forbid) or reboot/restart of server would rebuild the list the next
> time connection requests are made. The GUID in each database header serves
> no purpose other then to keep track of CURRENT attached databases.
> Obviously an extra read of the database file header is required for each
> connection which is an overhead if the database is already attached but one
> extra I/O is a small price compared to corruption. If mechanisms such as
> "KeepConnection=True" are not used then this may add to the applications
> overall speed.
>
>
>
> >>Instead, we'll have to live with IB5.6 for the time being - and hope that
> >>nobody makes a simple typing error when setting up a CLIENT workstation,
> or
> >>the database could be lost again.
>
> Rejecting connection strings by your application is the safest for the
> moment or move the DB to "C:" system disk but not recommended since
> speed/disk space will become an issue.
>
> Regards,
> Chris O'Rourke
>
>
>
> ************************************************************************
> * This message came from the list servers at http://www.mers.com *
> * To remove yourself from the list: send an email to listproc@... *
> * in the body of the message put: unsubscribe INTERBASE *
> * InterBase Search Engine http://www.mers.com/searchsite.html *
> * InterBase FAQ http://www.mers.com/faqinterbase.html *
> ************************************************************************
>