ERROR_SHARING_VIOLATION while calling fread()

[cbento]

Hi all,

I would like to discuss with u an error that is happening in my application.
The scenario is the following:

There is a thread in my application that opens a file and starts reading its contents. When the application reaches a certain point in the file, not always the same, fread return less bytes then what i told him to read. I check for eof condition, but this tells me that i havent reached the end-of-file yet. So i call ferror and i get the system error code 32, ERROR_SHARING_VIOLATION. The description for this error is: The process cannot access the file because it is being used by another process.
I can garantee that no more processes are trying to access my file or using it already.

What u think that is happening? any ideas?

Another thing that might be important to say is that this error only happens when I reboot the computer. In my application log file i can see that the error is writen to the log file some seconds before. This makes me think that the reboot has nothing to do with it. But also, when i dont perform a reboot the task runs clear.

thank u in advance

Cristóvão Bento

[Mick]

well I would try and rule out that nothing really does have a handle to your file, like anti-virus software.

use the file monitoring/system tools from www.sysinternals.com

[cbento]

That is a good idea, i am going to try that.

But anyway, when i open a file with my process, that file cannot be open by any other process right?! unless i specify the sharing options by using fsopen(). I open the file using fopen() function so if the file was already open by another process i would get an error when i tried to open it, which i didnt. So, if I am reading the file how can another process open my file? i still have my file open... i havent closed the handle. Do u agree with this? or there is something that i am missing here?

Cristovão Bento

[Mick]

Originally posted by cbento
That is a good idea, i am going to try that.

But anyway, when i open a file with my process, that file cannot be open by any other process right?! unless i specify the sharing options by using fsopen(). I open the file using fopen() function so if the file was already open by another process i would get an error when i tried to open it, which i didnt. So, if I am reading the file how can another process open my file? i still have my file open... i havent closed the handle. Do u agree with this? or there is something that i am missing here?

Cristovão Bento

for user mode apps that would be correct.

describe again where the shutdown comes into play? are you setting up to be notified when a shutdown occurs?

you say a few seconds before. Is that a few seconds before you actually inititate the reboot? or after you initiate the reboot, might be because the input buffer is being flushed because of the reboot.

[cbento]

The reboot come into play when i am reading the file. When i reboot the application gives the error i described, and still do some operations.
My application is not setup to receive a notification when the system shutsdown.

I am going to perform the following tests:

1 - Run the test with FileMonitor to check if the file is not open by another process
2 - I am going to setup my application to receive shutdown notifications
3 - I am going to open my file in a Shared Mode

Maybe with these tests i can understand better what is going on.

I want to thank u for your time. Some times, and if u are a developer u know the, we just reach a point where we need to discuss with someone what is happening in order to get new ideas to solve the problem. Once again thanks.

When i have more results i will post them here.

Cristóvão Bento

[Sam Hobbs]

Originally posted by cbento
But anyway, when i open a file with my process, that file cannot be open by any other process right?! unless i specify the sharing options by using fsopen(). I open the file using fopen() function so if the file was already open by another process i would get an error when i tried to open it, which i didnt.Note that fsopen() and fopen() are C runtime functions but they must use Windows SDK functions to do what they do in Windows. Therefore there will always be something specified for sharing mode.

[cbento]

Originally posted by Sam Hobbs
Note that fsopen() and fopen() are C runtime functions but they must use Windows SDK functions to do what they do in Windows. Therefore there will always be something specified for sharing mode.

of course, u are totally right. I think, but i am not sure, that in this case the fopen will specify no sharing properties for the file. What i mean is that the file can only be access by the procces that opened it, any other process that tries to obtain an handle to this file will fail.

What is your opinion on this?


Cristóvão Bento

[Mick]

Originally posted by cbento
of course, u are totally right. I think, but i am not sure, that in this case the fopen will specify no sharing properties for the file. What i mean is that the file can only be access by the procces that opened it, any other process that tries to obtain an handle to this file will fail.

What is your opinion on this?


Cristóvão Bento

sam is focusing too much on your wordage. Your meaning was clear when you first made your statement, so don't sweat it.

EDIT: not trying to be harsh or anything, I'm just saying lets not get distracted from the original focus, a sharing violation on shutdown, during a read operation.

[Mick]

to further clarify, because now I have to....

when you call fopen, no other processes can call sfopen and set a deny share, since you already have a file handle, it will fail.

when you call fopen, you allow sharing, but your read, should not fail with a sharing violation, there is something happening when you shutdown, that is the system is flushing the input buffer, which is causing your error.

[Sam Hobbs]

Originally posted by cbento
I think, but i am not sure, that in this case the fopen will specify no sharing properties for the file.What I am saying is that somewhere in the C runtime functions is a call to the CreateFile function, which is the only way in the Windows SDK I know of to "open" a file. The name "CreateFile" is misleading, since it does more than create files. It can even be used to get access to a disk drive.

Look at the third parameter (dwShareMode) of CreateFile. Note that there are four possible values for it:

0
FILE_SHARE_DELETE
FILE_SHARE_READ
FILE_SHARE_WRITE

If zero is used, then the file is not shared. Therefore there will always be a share mode, unless you want to define zero as being no share mode. I think that for the purposes of this discussion, the fact that zero means no sharing, it is reasonable to consider it to be a relevant share mode value.

[cbento]

Hello all,

first of all i want to thank u guys for the time u spent with my problem, thanks for the discussion we had about my problem, because of it i was able to solve my problem.

First of all, what Sam said is totally right, when we open a file the CreateFile API function gets called and the sharing parameter will be _SH_DENYNO. This permits read and write access by other processes.

Mick was also right when he said that it had to do with the operating system. After a few test cases, I discovered that, when a shutdown is issued, the operating system was taking over my file and creating the SHARED_VIOLATION error.

To solve this situation i followed Mick's idea, i implemented the shutdown detection on my server. When i detect a shutdown, i stop reading the file and i start closing my server. By doing this, my server works just fine.

When ever u need something guys just say, i am at your service.


King regards

Cristóvão Bento