Permissions and fopen
-
I'm using a call to fopen with the permissions of "a+" and writing logging information to the opened file. Unfortunately I'm now having to scale this to multiple programs and users. Is there some other permissions or even a different open file call that I can use that will ensure only one writer to the file and block any other opens? It seems that my current method allows multiple writers at the same time with the result that logging information is lost. Thanks. Chris Meech I am Canadian. [heard in a local bar] Remember that in Texas, Gun Control is hitting what you aim at. [Richard Stringer] Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
-
I'm using a call to fopen with the permissions of "a+" and writing logging information to the opened file. Unfortunately I'm now having to scale this to multiple programs and users. Is there some other permissions or even a different open file call that I can use that will ensure only one writer to the file and block any other opens? It seems that my current method allows multiple writers at the same time with the result that logging information is lost. Thanks. Chris Meech I am Canadian. [heard in a local bar] Remember that in Texas, Gun Control is hitting what you aim at. [Richard Stringer] Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
Firstly, if you are programming in MFC, please use CFile, instead of low level calls. You had like to be free of having to track resource handles and explicitly calling fclose(...) for every fopen. With CFile you can use the CFile::shareExclusive to accomplish what you would want. At API level you could pass the 3rd parameter to CreateFile(...) as 0, it is actually the dwShareMode. If you plan to use the CRT routines, still , fo ahead and have a look at _locking(...)
-
Firstly, if you are programming in MFC, please use CFile, instead of low level calls. You had like to be free of having to track resource handles and explicitly calling fclose(...) for every fopen. With CFile you can use the CFile::shareExclusive to accomplish what you would want. At API level you could pass the 3rd parameter to CreateFile(...) as 0, it is actually the dwShareMode. If you plan to use the CRT routines, still , fo ahead and have a look at _locking(...)
Thanks for the tips. Converting to a CFile looks to be the way to go. The fopen calls are from 10 year old library code that's never been touched. :-O Chris Meech I am Canadian. [heard in a local bar] Remember that in Texas, Gun Control is hitting what you aim at. [Richard Stringer] Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
-
Thanks for the tips. Converting to a CFile looks to be the way to go. The fopen calls are from 10 year old library code that's never been touched. :-O Chris Meech I am Canadian. [heard in a local bar] Remember that in Texas, Gun Control is hitting what you aim at. [Richard Stringer] Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
it wont help the problem is not your fopen but the multiple process access. u can several things. here are 2: 1. lock on a mutex with a name derived from the file's name. 2. if u can't open, Sleep for 10ms and retry repeatedly if u just enable other processes to touch the file while u write it, u will very quickly garble the file btw - in my openion fopen is much better than CFile
-
it wont help the problem is not your fopen but the multiple process access. u can several things. here are 2: 1. lock on a mutex with a name derived from the file's name. 2. if u can't open, Sleep for 10ms and retry repeatedly if u just enable other processes to touch the file while u write it, u will very quickly garble the file btw - in my openion fopen is much better than CFile
-
hmm , then what are those flags built in the operating system for? They are just for that. Don't reinvent the wheel with mutexes and make the code a mess. Vipin - MVP
You are wrong here. Sharing flags are supplied to answer any possible user's need in creating/opening any kind of stream(file/pipe/sock...) but nobody said you could trust the sharing flags to automatically synchronize the read/write operations. Thread synchronization is the user's responsibility and using a named mutex is very simple and generic solution. In cross-process scenario the solution must include a lock/spin on a global object so these are the options: 1. The file itself, that can be locked on opening, so the other task should spin on CreateFile till success. 2. Lock on a named mutex 3. Use some other shared info like the registry