|
|
|
As the FairCom Server manages file open/close operations for multiple users, it is critical for it to recognize uniqueness of a file. Different users can refer to the same physical file using different file names through aliases, relative paths, device mappings or SUBST commands. Internally, the FairCom Server has tests to determine if two files with different names are really different, or are actually the same physical file being accessed with different paths or alias names. If this internal unique file test is not accurate, the FairCom Server may attempt to open the files as two separate physically different files. This presents many problems as the FairCom Server is then managing two separate caches for the same file - data integrity can no longer be enforced in these situations.
In some cases, when confronted with file names mapped across a network or referred with UNC syntax, such as “\\mymachine\c\mydata\myfile.dat”, this internal unique file test incorrectly determines two separate files are being addressed, when actually, the same file is being accessed. One user is using a physical name, while another was is using a UNC name. This problem, while uncommon, leads to serious consequences. As such, FairCom DB performs a number of protections.
This option disables attempts to determine if two files accessed with different file names (or paths) and which have identical FairCom DB file IDs are actually the same or different files. This support is added in case our tests for uniqueness are somehow incomplete and lead to unintended file ID reassignments. These modifications give FairCom DB the capability to disable the uniqueness test when files are suspected of having the same internal, “unique” 12-byte ID.
COMPATIBILITY EXACT_FILE_NAMES
This option mandates that all files have the exact same file name in order to be opened. If the internal name test determines that the files are in fact the same physical file, it will not allow the file to be opened with a different name. This compatibility keyword does not permit the same file to be opened with different names. If the same file is attempted to be opened with a different name, then error EXCT_ERR (642) will be returned.
There is a subtle interaction with the NO_UNIQFILE keyword defined above. The possible outcomes for all the combinations of keywords and files are in the table below. A file is represented by a lower case path, an uppercase name, and a numeric file ID. For example, pA1 has path ‘p’, name ‘A’, and file ID 1. pA1 and qA1 are the same file accessed with different paths; pA1 and qB1 are different files mistakenly having the same file ID; and pA1 and qB2 are two different files with different file IDs (as expected).
Four possible keyword combinations are possible:
Standard |
Neither NO_UNIQFILE nor EXACT_FILE_NAMES |
NoUnique |
Only NO_UNIQFILE |
Exact |
Only EXACT_FILE_NAMES |
Both |
Both NO_UNIQFILE and EXACT_FILE_NAMES |
In the outcomes table below, the first (successful) open is for file pA1. The second open is as indicated. In actuality, only the second open for qB1 requires some adjustment or an error return.
Second Open |
Standard |
NoUnique |
Exact |
Both |
|---|---|---|---|---|
qA1 |
NO_ERROR |
NO_ERROR |
EXCT_ERR(642) |
EXCT_ERR (642) |
qB1 |
Modify B’s file ID and return NO_ERROR |
Incorrectly treat B as a shared open of A and return NO_ERROR |
Modify B’s file ID and return NO_ERROR |
EXCT_ERR (642) |
qB2 |
NO_ERROR |
NO_ERROR |
NO_ERROR |
NO_ERROR |
The uniqueness test (which is based on system dependent calls) may incorrectly indicate that two files are unique when they are the same. This occurs with certain mappings and/or aliases masking the sameness of the files. If this occurs, the first row of the above table becomes:
Second Open |
Standard |
No Unique |
Exact |
Both |
|---|---|---|---|---|
qA1 |
Incorrectly reassign file ID and have same file opened as two different files. |
NO_ERROR |
Incorrectly reassign file ID and have same file opened as two different files. |
EXCT_ERR (642) |
The most conservative approach is to turn on both keywords, but of course this requires the same name (and path) to be used for a file on all opens. If the uniqueness test is without weakness, then the standard setting (i.e., neither keyword) works best.
LOCAL FILE TEST
Because of the potential problems with network file names, and because FairCom does not recommend (and discourages) placing FairCom Server files or logs on network drives (e.g. drives NOT on the local machine running the FairCom Server executable), a warning message is logged to CTSTATUS.FCS if a network file is detected. Besides the potential problem for the unique file test, placing data/index or server log files on a mounted network drive will introduce an additional network overhead and jeopardize the server’s performance. The WARNING is only issued on the first such occurrence to avoid unnecessary overhead. If either of the COMPATIBILITY keywords is active, NO_UNIQFILE or EXACT_FILE_NAMES, the issue described above is not in play and FairCom DB automatically disables this test.
Due to the possibility of a performance hit, the COMPATIBILITY NO_TEST_LOCAL keyword is available to turn off the check of whether a file is local or remote.
