| Subject | Re: [firebird-support] Re: Database file in mapped drive |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-10-06T10:53:04Z |
At 10:03 AM 6/10/2004 +0000, you wrote:
care about the data, just go ahead and try your worst.
Understand that a Firebird database is not a series of physical structures
that filesystems recognise as "tables" and "records". It is one dynamic
chunk of disk (not necessarily in a single chunk nor even on a single
physical disk or partition) that is controlled by the same resource
accounting system that the server runs under. Externally, the machine's
file accounting knows only about the "file" - that dynamic chunk that grows
and shifts in ways it cannot track. In a multi-file database, the
filesystem has no knowledge that the physical files have any logical
connection to one another. The server asks for disk resources, which it
proceeds to allocate as "pages". It keeps its own accounting of what it
stores, and where.
As for "processes opening the database", there is only one process that
opens databases - the server. Applications don't open databases - though
they can open them as files, with disastrous consequences to the database
if it has clients active. Applications pass requests through the API and,
in the case of Superserver, a SINGLE exclusive process is opened when the
first client request comes through the API. After that, all client
connections are threads of that single process. In the case of Classic,
each client-to-server attachment request (if successful) starts a discrete
process, obviously not exclusive.
Operations inside the database are tightly bound to resource calls to the
operating system. If the database file is physically removed from the
system that should be processing those calls, it's literally pot luck as to
what happens to data, since the server can't traffic resource calls with a
foreign host.
On Windows, I think it's pretty hard to succeed in connecting to a database
located on a share or a mapped drive. There are several inaccessible
layers to get past. I've heard of cases where it's been claimed to have
happened, though I've never been able to do it.
On Linux, with RemoteFileOpenAbility set true, I have managed to connect to
and corrupt a database that was created for the purpose -- so I know it
works as designed.
./heLen
>In our system there is only one process opening the database. WeOnly irretrievably and unpredictably corrupted databases. So, if you don't
>were thinking of storing the file in a disc in other machine and
>accessing it by a mapped drive just for security reasons. What are
>the riscs of doing this ( for the risk-affine people :-) )?
care about the data, just go ahead and try your worst.
Understand that a Firebird database is not a series of physical structures
that filesystems recognise as "tables" and "records". It is one dynamic
chunk of disk (not necessarily in a single chunk nor even on a single
physical disk or partition) that is controlled by the same resource
accounting system that the server runs under. Externally, the machine's
file accounting knows only about the "file" - that dynamic chunk that grows
and shifts in ways it cannot track. In a multi-file database, the
filesystem has no knowledge that the physical files have any logical
connection to one another. The server asks for disk resources, which it
proceeds to allocate as "pages". It keeps its own accounting of what it
stores, and where.
As for "processes opening the database", there is only one process that
opens databases - the server. Applications don't open databases - though
they can open them as files, with disastrous consequences to the database
if it has clients active. Applications pass requests through the API and,
in the case of Superserver, a SINGLE exclusive process is opened when the
first client request comes through the API. After that, all client
connections are threads of that single process. In the case of Classic,
each client-to-server attachment request (if successful) starts a discrete
process, obviously not exclusive.
Operations inside the database are tightly bound to resource calls to the
operating system. If the database file is physically removed from the
system that should be processing those calls, it's literally pot luck as to
what happens to data, since the server can't traffic resource calls with a
foreign host.
On Windows, I think it's pretty hard to succeed in connecting to a database
located on a share or a mapped drive. There are several inaccessible
layers to get past. I've heard of cases where it's been claimed to have
happened, though I've never been able to do it.
On Linux, with RemoteFileOpenAbility set true, I have managed to connect to
and corrupt a database that was created for the purpose -- so I know it
works as designed.
./heLen