Windows has the ability to share concurrent access to files through mechanisms such as byte-range locks, whereby a process locks only a certain region of a file, etc. But applications have to be written appropriately to take advantage of this. It is entirely possible to code your application in such a way that you lock the entire file, and not just a region of it. You can even lock a file so that another process cannot even read from it.
However, you complicate things when you talk about accessing a file on a network file share. Now we're accessing files over the SMB network protocol.
SMB uses oplocks (opportunistic locks) and leases to manage concurrent access to files. The types of oplocks and leases are as follows:
Oplocks
- Level 1, exclusive access This lock allows a client to open a file for exclusive access. The client may perform read-ahead buffering and read or write caching.
- Level 2, shared access This lock allows multiple, simultaneous readers of a file and no writers. The client may perform read-ahead buffering and read caching of file data and attributes. A write to the file will cause the holders of the lock to be notified that the lock has been broken.
- Batch, exclusive access This lock takes its name from the locking used when processing batch (.bat) files, which are opened and closed to process each line within the file. The client may keep a file open on the server, even though the application has (perhaps temporarily) closed the file. This lock supports read, write, and handle caching.
- Filter, exclusive access This lock provides applications and file system filters with a mechanism to give up the lock when other clients try to access the same file, but unlike a Level 2 lock, the file cannot be opened for delete access, and the other client will not receive a sharing violation. This lock supports read and write caching.
Leases
- Read (R), shared access Allows multiple simultaneous readers of a file, and no writers. This lease allows the client to perform read-ahead buffering and read caching.
- Read-Handle (RH), shared access This is similar to the Level 2 oplock, with the added benefit of allowing the client to keep a file open on the server even though the accessor on the client has closed the file. (The cache manager will lazily flush the unwritten data and purge the unmodified cache pages based on memory availability.) This is superior to a Level 2 oplock because the lease does not need to be broken between opens and closes of the file handle. (In this respect, it provides semantics similar to the Batch oplock.) This type of lease is especially useful for files that are repeatedly opened and closed because the cache is not invalidated when the file is closed and refilled when the file is opened again, providing a big improvement in performance for complex I/O intensive applications.
- Read-Write (RW), exclusive access This lease allows a client to open a file for exclusive access. This lock allows the client to perform read-ahead buffering and read or write caching.
- Read-Write-Handle (RWH), exclusive access This lock allows a client to open a file for exclusive access. This lease supports read, write, and handle caching (similar to the Read-Handle lease).
Windows Internals 6th ed., Mark Russinovich, et al.
None of these modes are going to give you the shared write access you seek.
Change your strategy. Like MDMarra said, the Windows event log is a better choice. Another idea would be to have all the clients write to their own files in the file share, then have a server process collect all the files and aggregate them. You mention in your question that you're writing code, so you're in a position to change how this application works. I would suggest going to StackOverflow and asking them about the best way to approach shared write access to a single file over the network.
