Microsoft KB Archive/66473

OS/2 LAN Man: File Locking Bhvr Works Differently over Network ID Number: Q66473

2.00 OS/2

Question:

I have two programs that try to lock/unlock a file locally or over a network. Program 1 (Writer) opens a file for read/write access, with no other writers allowed. It locks the file, writes out some data, and then unlocks the file.

Program 2 (Reader) opens this same file for read-only access. It locks the file, reads in some consistent data, and then unlocks the file.

Suppose the Writer program has the file locked, and the Reader program wants to read this same file. The Reader program tries to lock the file, but this fails because the Writer program has already locked the file. The Reader program delays for a little while, and then tries to lock the file again. Eventually, the Writer program will finish writing and will unlock the file. The next time the Reader program tries to lock the file, the lock will succeed.

This works correctly with local disk files, but doesn’t work correctly for files that reside on a remote server. Once the Reader program gets a lock violation error on a remote file, all subsequent attempts to lock the file fail with the same error, even after the Writer program unlocks the file. In fact, the Reader program can’t lock the file until the Writer program closes the file.

The following output is produced when a third program is run that has two threads in it. Thread 1 simulates access by the Writer (program 1) program, and thread 2 simulates access by the Reader (program 1) program. The threads try to lock a file named “testfile”. Thread 1 unlocks the file after some time, so that thread 2 can lock the file.

The output listed below occurs when “testfile” resides on a local disk:

Thread 1: File open Thread 1: File locked Thread 2: File open Unable to do lock #2: testfile, error 33 Unable to do lock #2: testfile, error 33 Unable to do lock #2: testfile, error 33 … Thread 1: File unlocked Thread 2: File locked Thread 2: File unlocked Thread 2: File closed Thread 1: File closed

If you run this same program with “testfile” residing on a remote disk, you get the following output:

Thread 1: File open Thread 1: File locked Thread 2: File open Unable to do lock #2: testfile, error 33 Unable to do lock #2: testfile, error 33 Unable to do lock #2: testfile, error 33 … Thread 1: File unlocked Unable to do lock #2: testfile, error 33 Unable to do lock #2: testfile, error 33 Unable to do lock #2: testfile, error 33 … Thread 1: File closed Thread 2: File locked Thread 2: File unlocked Thread 2: File closed

Please note that the lock attempt in thread 2 (the Reader program) fails even after the Writer program unlocks the file. In fact, the lock attempt by the Reader program doesn’t succeed until the Writer program closes the file.

Response:

This behavior is not considered to be a problem with the OS/2 LAN Manager. This behavior is an optimization being performed at the workstation end. If a file has been opened in Deny-Write mode, by default, the workstation will buffer I/O on that handle similar to Deny-None or an OpLocked file. This normally can be done because the workstation knows that the contents of the file cannot change. In some cases, the buffering of a Deny-Write file handle can cause a problem (normally with Locking and Unlocking requests). The wrkheuristic number 23 can be used to turn off buffering for Deny-Write file handles.