WritePrivateProfileString.... close file?

I am getting a periodic corrupted data file in our application. This file is based on an INI file layout and is handled using....

WritePrivateProfileString
ReadPrivateProfileString

Because this routine basically "opens" the file that is passed to it to read or write the data, the one thing I am thinking is that that file is not being closed. I added a bunch of

Quote:

---

WritePrivateProfileString(NULL,NULL,NULL,filename);

---

to flush the cache out, but still running into this problem.

So the question is... is there a routine or call that we should make to "close" the file when done reading or writing?

Thanks

Are you calling these methods from multiple threads?

Actually, it is a bit of "legacy" code that has worked for many years... just started corrupting the file periodically and haven't been able to figure out why.

Answer to your question, Yes and no.... there are several subroutines that call the reads and writes to this file. When I inserted the cache flushes, I put it right after the last write in each subroutine. Didn't put them in any routine that reads, cause technically, nothing changed. Although, old programming habits, says the file is still open.

Quote:

---

Originally Posted by pbrama

Actually, it is a bit of "legacy" code that has worked for many years... just started corrupting the file periodically and haven't been able to figure out why.

---

Maybe there was always a bug, and finally it's been exposed. Just because an app works, regardless of the number of years, doesn't mean it doesn't have hidden bugs or holes.

How many machines has this software been running on? If it's only one or two machines, that is more of a reason to expect bugs, since it really wasn't field tested amongst thousands of users running the program on their hardware.

It may be that you're corrupting memory or doing something else illegal, and in all these years, there was no visible effect. You may have happened to get away with it up until now.

Are you checking the return value for WritePrivateProfileString() (to be more precise, all API function calls)? If not, and your code assumes these functions return OK, maybe that is the problem. Your program is taking the "success" path, when in reality, it shouldn't.

Quote:

---

there are several subroutines that call the reads and writes to this file. When I inserted the cache flushes, I put it right after the last write in each subroutine. Didn't put them in any routine that reads, cause technically, nothing changed. Although, old programming habits, says the file is still open.

---

Cache flushes? Sounds like you we're reaching in the dark for a solution and hoping it stuck.

WritePrivateProfileString has sophistication added to it with the newer operating systems. It doesn't work the same way as it did with older Windows operating systems. It is imperative you check return values for this function, as it isn't as straightforward as to what is going on internally as with older Windows operating systems.

See here for an example:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
http://social.msdn.microsoft.com/for...6-92fdfa5a9707

Regards,

Paul McKenzie

Quote:

---

Originally Posted by pbrama

Actually, it is a bit of "legacy" code that has worked for many years... just started corrupting the file periodically and haven't been able to figure out why.

Answer to your question, Yes and no.... there are several subroutines that call the reads and writes to this file. When I inserted the cache flushes, I put it right after the last write in each subroutine. Didn't put them in any routine that reads, cause technically, nothing changed. Although, old programming habits, says the file is still open.

---

So to answer my question..., could you answer my question?

I still don't know if you are calling the read/write profile api's from different threads, are you?


If you are and you aren't synchronizing access to the calls with a critical section or a mutex, that could be the cause of the corruption you are seeing.

Microsoft documentation doesn't specify WritePrivateProfileString/ReadPrivateProfileString thread safety. According to some articles:
http://social.msdn.microsoft.com/for...7-48dc5d4031a4
http://blogs.msdn.com/b/junfeng/arch.../06/68152.aspx
both functions are not thread safe. You need to synchronize all calls to these functions for the same file.

Quote:

---

Originally Posted by pbrama

Because this routine basically "opens" the file that is passed to it to read or write the data, the one thing I am thinking is that that file is not being closed.

Thanks

---

I would think that's a faulty assumption. How are you "opening" it?

Quote:

---

Originally Posted by pbrama

I am getting a periodic corrupted data file in our application. This file is based on an INI file layout and is handled using....

WritePrivateProfileString
ReadPrivateProfileString

---

So is your file an INI file or is it just "based" on INI file?
Is there any access to this file other than via these two API calls?
When you open this file in some text editor, is it corrupted?
And what exactly do you mean by "corrupted"?