Helen Borrie wrote:

> At 10:51 AM 14/06/2003 -0400, you wrote:
>
>>Helen,
>>
>> The risk is simple. A database on a share will be corrupted
>>if it is opened by the system that "owns" the disk and the one
>>that "shares" it. Not may be corrupted. Will be corrupted.
>
>
> So - guess my next question.
>
> I'll help. "Why in glory do we have a conf parameter to PERMIT it???"
>

Ann is casting a fairly gloomy picture of it.

It's a feature for the knowledgable user, but in cases where you have
only one db server machine anyway, or databases that are only ever
accessed by one program it's as safe as houses.

nfs drives are normal for general user usage, often you don't have root
access to the nfs server and since user areas are often exclusively from
another nfs machine, it leave you with just /tmp on your workstation
where databases will work.

I've been hit by it quite often, working in a general unix environment,
it also has unexpected side effects, you can't build the firebird engine
on a nfs drive for instance, or run a firebird db (outside of /tmp) on
my user account at sourceforge.

Persoanlly, although I understand the reasoning behind it, I think the
server that owns the db should be specified explicitly (say via Dmitry's
alias file, or perhaps first machine to open it, assumes ownership).
Currently it's restricted so that database server that "owns" a db has
to be the machine that owns the physical disk. Which is useful, but
occasionally you want to break that restriction.


Cheers

Mark