Last updated:
November 11, 1998
Background
Due to a bug in Windows or a non compatible way that Pragma 5 implements low level PFM file locking during read and write operations, file corruption can result when two users of a Windows network try to lock and access the same file. See the Technical bulletin Windows Network and PFM Files Corruption.
As of version 5.42.1 a different, more secure way of low level locking a file has been implemented.
Technical
After locking the control unit the Process ID written in the file is read, and if the value is 0 (meaning free) the process ID number of the machine that requests a lock is written to the file. Then the Process ID of the file is read again, and only if it contains the process ID number of the machine, the process continues. In other words, unless the file contains the process ID of the machine that requests the lock, no reading or writing to the file is possible.
The process ID is written to the file header, in a free byte where the file version is stored.
Implementation
To implement strong network locking you must first assign a unique Process ID number to each workstation on the network. Any numbers between 1 and 255 will do, as long as each workstation has a unique number (go to Tools, Options, Various options to do this).
Be aware that by default a workstation has a Process ID of 0 (zero). If you implement strong network locking on a workstation with the Process ID of 0 (zero) Pragma will crash.
Then go to Tools, Options, File Manager and check the enable strong network locking check box.
Validate all the files on the server to ensure that they all have been previously unlocked correctly. You must use version 5.42.1 of Prutil or later to do this.
Possible Problems
It is possible that due to a workstation crash a file contains a Process ID, yet the lock is not owned by anybody. That file becomes inaccessible to everybody except to the workstation that caused the crash and the workstation that tries to access the file will hang. The only way out is to kill the Pragma 5 process with CTRL-ALT-DEL. To render the file accessible again you must validate it.
Both the Process ID and the flag to enable strong network record locking are stored in the registry in: HKEY_CURRENT_USER, SOFTWARE, Logical Pragma, Initialization.
Warning
Although strong network locking is meant to be used in a network, once enabled, all PFM file access, regardless of where the files are located, is done with strong network locking. This includes the system files PRMSG.PFM, PRST.PFM and PRVOCAB.PFM.
When using strong network locking you must implement it on all machines on the network.
Technical in Depth
The Process ID is written to the file in the structure flconst.dataversion, using a free byte. The actual writing and reading is done with the functions read fileprocessid() and writefileprocessid(), in the library module FM.C.
To view the process ID in a file (note that unless there was a problem, the location must contain 0) use Prutil, View PFM. Select the file and the view Control. The first line looks like this:
| 00 | 01 | 00 | 00 | 03 | 80 | 00 | 00 | F4 | 00 | 00 | 00 | 00 | 08 | 00 | 00 |
The data version occupies a double word at offset 4 of any file, which in the above example is 03 80 00 00.
When the data version contains a process ID of say 5 (meaning the files is locked by the machine with the ID number of 5), the double word looks like this: 03 80 00 05.
Such a file can only be accessed by a machine that has strong networking enabled if it has an ID number of 5. If strong network locking is not enabled, any machine can access the file, but will not clear the byte. To clear the byte you mast validate the file or manually patch it.
Pragma 5
In Pragma 5 (version 5.42 build 3 and up) you can use strong network locking whether you write back the noun values to the vocab or not.
Pragma 4
Pragma 4 version 4.42 of Pragma 4 does not work correctly when strong network locking is enabled:
For the above reasons we do not suggest that you use Pragma 4 with strong network locking.
Remember that the problem is caused using Windows NT server and Windows network. Pragma 4 never had or has a problem on a Novell network.
Due to other pressing issues we cannot invest much time at this moment to fix the problem. What you can do:
