Commented by: Sean Leyne (seanleyne)

Using a single folder/path for these files only works if a single FB instance is installed. There would be problems if multiple instances/versions were installed.

Commented by: @dyemanov

This directory must be well-known and fixed to all FB processes running on the machine, otherwise you may get your database corrupted. This makes any per-instance or per-database configuration problematic. But if you insist, use the FIREBIRD_LOCK environment variable to point the engine to the new destination.

Commented by: Holger Klemt (klemmo)

thanks, i was not aware of this existing FIREBIRD_LOCK variable, works fine

Am i right that looking at gds.cpp in Firebird Source code will always help to find similar
variables in the future?

const char* const FB_LOCK_ENV = "FIREBIRD_LOCK";
const char* const FB_MSG_ENV = "FIREBIRD_MSG";
const char* const FB_TMP_ENV = "FIREBIRD_TMP";

Commented by: @dyemanov

Basically yes, although I cannot promise it won't be moved elsewhere due to some refactoring :-)

Commented by: Sean Leyne (seanleyne)

Dmitry, why "won't fix" it seems like a reasonable request, allowing for the path of related files to be defined/configured on an instance by instance level.

Commented by: @dyemanov

Did you read my comments above? How are you going to protect a database accessed by multiple instances configured differently?

Commented by: Sean Leyne (seanleyne)

The fact that something is dangerous to do, does not mean that we should not allow it -- documentation/comments in config file should provide necessary warnings.

IMO, support via environment variable is not appropriate but an instance level configuration setting seems reasonable.

The scenario that Holger has brought forward is entirely valid and should be supported.

Commented by: @dyemanov

Undoubtfully, /tmp disk speed matters a lot for the overall performance. But does anyone have a proof that the same is true for files backing the shared memory in Firebird? Why would one need to relocate them? Just because it *looks* useful?

Practice shows that too few people read docs and many of those who do cannot handle all the subsequences. A config option allowing to corrupt a database is a disaster waiting to happen. Sometimes it could be rational even if not recommended (e.g. RemoteFileOpenAbility) but I doubt this case belongs to the same category.