|
|
|
CHECK_FILENAME_VALIDITY keyword for backwards compatibility
Disallow create or open of file with drive-relative path
CHECK_FILENAME_VALIDITY YES | NO
FairCom DB V12 and FairCom RTG V3 forward no longer support “Drive-Relative” Paths by default. The purpose is to ensure predictable, safe, and secure behavior. and all files must be opened using an absolute file path. For backwards compatibility, you can restore prior behavior by adding the CHECK_FILENAME_VALIDITY NO configuration option to ctsrvr.cfg.
On Microsoft Windows,® FairCom uses the concept of a "Drive-Relative Path" as an easy way to specify a relative path to where the database is installed on a drive. The path includes a drive letter without a following backslash. For example, C:mydirectory\test.dat is a drive-relative path because there is not a backslash after the drive specification (C:). On the other hand, C:\mydirectory\test.dat is not a drive-relative path; it is an absolute path. A drive-relative path is relative to whatever happens to be the current working directory of the database on that drive. A process may have a current working directory for each drive.
For example, if the working directory on C: is C:\FairCom, then the drive-relative path C:mydirectory\test.dat is equivalent to C:\FairCom\mydirectory\test.dat while the absolute path C:\mydirectory\test.dat is unaffected.
Drive-Relative Paths can cause behavior that is unpredictable, unsafe, or unsecure. Thus, the database now returns an error when a Drive-Relative Path is specified in a call to create or open a file.
Compatibility Notes: This modification breaks compatibility by disallowing certain file names that used to be allowed. The preferred solution is to use a full path. (A less preferable solution is to use the configuration option CHECK_FILENAME_VALIDITY NO in ctsrvr.cfg. This option can also be changed at runtime. In standalone mode, this behavior is controlled by a field in the CTGVAR structure, ctCheckFileNameValidity. Setting it to a non-zero value enables the check; setting it to zero disables the check.)
Index Node Prune Feature - Ability to deactivate node pruning
FairCom DB's delete-node thread prunes empty nodes from index files in the background. It densely packs key data for optimal index performance. To prevent index corruption, it runs during idle times and opens the index file exclusively, which prevents external processes from opening it.
To disable the "index node prune" feature, for example to allow an external process to open an index file, use the following keyword:
COMPATIBILITY NO_DELNOD_QUEUE
The above keyword prevents the delete-node thread from running, which prevents automatic index optimization, however, it allows external processes to open the index file.
Another keyword, COMPATIBILITY KEEP_EMPTY_NODE_ON_READ, prevents empty nodes read from disk being added to the delete queue. This is the V2/V11 and earlier behavior.
Compatibility Note: This change breaks compatibility.
