Can multiple computers simultaneously append to a file on a windows file share?

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.

No. Once a file is opened for writing, it's locked. Other attempts to write while locked will result in "Access Denied."

You should consider writing whatever these events are to the local event logs and then use Event Log Subscriptions to pull all of these logs into a central source. From there, you can export it to whatever format you wish.

Another way of dealing with this problem might be to have each machine have an exclusive lock on the file while writing and releasing it immediately thereafter, and also have each machine programmed with a loop that tries to obtain write accessto the file, and, upon receiving an "access denied" message simply retries until the file is available. This person's need is to append short length log messages to the common file. Thus each machine would lock the file only briefly. A loop for obtaining an exclusive write lock would quickly obtain write access. Provided each process writes in append mode, I believe this should provide the needed function, whereby each machine adds to the log file as required.