Mutual Exclusion on .txt file

[nmunro]

I've got a problem with an application that has recently gone mutli-user from single user.

A bug has reared its head in that a file which receives output from the application is now shared between multiple users and is causing deadlock to occur.

A single file is obviously not the best way to handle output in a multi-user system but it's legacy, the app's going to be replaced in a couple of months and we can't spare the development time to completely rethink the output method.

So: How can I achieve mutual exclusion on this one file?

Firstly i'll explain how the deadlocks are occuring.

Our app writes out data that's picked up by another system to a txt file called x.dat. When we write to the file, the first thing we do is rename it to x.pre so that the polling process on the other system can not pick up the file mid-write.

Our app then renames the file to x.dat once it's finished writing.

Since the polling system deletes the file when it retrieves it, our app has to be able to create a new file if one does not currently exist.

The symptoms of the deadlock were that occasionally, x.pre and x.dat would exist simultaneously. The process that wrote the .pre file would not be able to rename to .dat because it already existed and would fail with error.

I then added deadlock handling code to the app which stated that if the .dat exists before we try to rename .pre (to .dat), then append .pre to dat and delete the .pre.

I believed this would cure the problem but the deadlock still occurs in a slightly different manner. Now when deadlock occurs, it is the .pre file alone that is left in the directory alone. And seeing that the main purpose of renaming to .pre is to prevent other processes writing to/picking up the file, again we are in a deadlock situation.

Has anyone got any ideas as to how this could be occuring?

[LeeND]

I don't know if this is an option, but on the Windows NT-based operating systems you have the ability to use "_fsopen" to open the file directly in a deny-access-to-others mode. Use _SH_DENYRW mode when opening it and have other clients sleep and loop and try again when they get "access denied"?

What this would let you do is avoid the whole problem of ".pre" versions of the ".dat" file and let all the clients compete for access to open/edit/modify/save the file in place.

In other words, let the OS do the locking for you.

[nmunro]

File level locking was something i'd been thinking about, i've just found out that more than half our users hadn't updated the version to the "deadlock free" version i released yesterday (sigh). This means that i'll have to wait and see if the changes I made make any difference.

If this doesn't work, i'm still left with the problem of .pre and .dat because the original purpose of this variation was to stop the outside process picking up the file mid write.

I don't know how that process would react if such a thing would happen...

Thanks for the help though, I know it was a long post so much appriated!