> Now, there are a few different issues here.
>
> [1] Linkage of lock file to a file system path
>
> In my understanding FB only needs a named shared memory area. Why is
> it mapped to a file system path? Just as a convenient uri? Or are
> there other reasons?

As i understand WinAPI we can't create shared memory area without
giving it the file name

> [2] Unique id
>
> The shared memory area needs a unique id, whether it is a path or not.
> It needs to be determenistic, so that each classic instance can mmap

Agreed

> it in. The default could be something like FIREBIRD.ODSXXX.PORTNO, as
> was already suggested in this list. Adding a port number makes it
> easier to have multiple instances of the same provider on a single
> piece of H/W.

Please, don't touch port number :) There are many ways to communicate
with server and TCP\IP is not exclusive one. We can talk here about server
instance name but it is also not necessary. If we continue to use server-wide
lock table all we need is to distinguish lock tables of different formats. I.e. we
can name it as we do now (host name at the root dir) plus lock table format
number suffix. If we will use per-database lock tables we can add suffix to the
full database file name to name lock table.
Am i missing something ?

But this nice automatics default names will not solve a real problem.
What problem ? See below...

...

> [4] Fool proof
>
> I think we should try to at least generate a warning if a specific
> setup has the potential to hurt data. Making it possible to have two
> instances of a provider on the same box, using different lock files,
> accessing the same db is perhaps not such a good idea.

Agreed

> It is another ODS change, but would it make sense to have to store the
> name of the lock file used by the first instance accessing a db in the
> header page, and blocking access using other lock files for instance
> 2, 3, etc.?

This can prevents database to move to the another machine where
path (stored in header page) to the lock table not exists.

But real problem is that we have no robust mechanism to guarantee
that only one instance of lock manager can work with particular database.

Imagine we have two separate directories with FB 2.x installed. They
have different root directories of course. We run classic servers, configured
to use different port numbers (or even simpler - we can use local mode on
linux). Then we can access same database via this two different instances
of Firebird using different lock tables !

And Vulcan's config stuff can't prevent such problem too - we can open the
same database via Firebird and via Vulcan simultaneously

Regards,
Vlad