1

I have a program that reads a set of files, closes them, and then attempt to delete them.

Sometimes (not always, but pretty often) the delete fails with 'sharing violation' error.

Using sysinternals process monitor I saw that in these cases the close operation wasn't reflected in the process monitor.

It appears that sometimes the close system call is skipped for no apparent reason, and without any exception.

This is happening on a windows 7 64bit machine using visual studio 2010.

Code sample;

void readFile(string file)
{
  ifstream stream(file);
  string line;
  while(getline(stream, line))
  {
    cout << line << endl:
  }
  stream.close(); // this is redundant
}

// calling code:

readFile(file);
if(remove(file.c_str()) != 0)
{
  cout << "file deletion failed" << endl;
}
Alok Save
  • 202,538
  • 53
  • 430
  • 533
Ophir Yoktan
  • 8,149
  • 7
  • 58
  • 106
  • 3
    A minimal testcase that reproduces the problem would be nice. – Xeo Dec 28 '11 at 06:53
  • The relevant code is preety scattered, so copying all the relevant code is problematic. Also, the same code worked in other applications without any problem. – Ophir Yoktan Dec 28 '11 at 06:58
  • 1
    If the code is scattered then try to create a minimal code sample which will reproduce the problem, Most likely the problem will reveal itself to you when you do so.Without code the answers will be mere speculation and nothing else. – Alok Save Dec 28 '11 at 07:03
  • Are you using *pointer* to fstream? Or, maybe, you're using pointer to the class which has fstream has member? – Nawaz Dec 28 '11 at 07:03
  • 1
    If the code is too scattered to copy, it's probably too scattered to fix. Rein it in, simplify it, or learn to live with the crashes. – Beta Dec 28 '11 at 07:05
  • Nawas its a local variable. And I tried both implicit close (variable goes out of scope) and explicit close (using the close() method – Ophir Yoktan Dec 28 '11 at 07:07
  • Ophir Yoktan: if the variable went out of scope, that's a clear sign that there's another handle somewhere in your code. – Mooing Duck Dec 28 '11 at 07:28
  • @Mooing Duck. note that I also monitored the program using process monitor, and in the problematic cases the close system call wasn't seen (while in the good cases it was seen) – Ophir Yoktan Dec 28 '11 at 07:35
  • "The other handle" could easily be in your anti virus program checking what you just did to the file. – Bo Persson Dec 28 '11 at 08:17
  • @Bo Persson: as I said, in most cases I see that a CloseFile operation was performed by the OS. In the problematic cases the operation wasn't performed by the OS. – Ophir Yoktan Dec 28 '11 at 08:27
  • Check if close fails. Read this as well: [link](http://blogs.microsoft.co.il/blogs/pavely/archive/2010/11/24/the-case-of-the-unexplained-sharing-violation.aspx) – reder Dec 28 '11 at 09:09
  • Hy, I am experiencing the exact same behavior. Did you find a solution to your problem? – denim Jun 06 '17 at 13:10

2 Answers2

0

This could happen if you are creating processes in-between using CreateProcess with bInheritHandles=true. The new process will inherit the file handle and the file won't be closed by your main process as there is still an outstanding handle. This may explain why you can't see the close operation in Process Monitor, the OS will close the file once all handles have been released.

trigg
  • 46
  • 4
0

Firsty your code is lacking a ;. Change this cout << line << endl: to this cout << line << endl;

Here's a similar problem : Any reason why an std::ofstream object won't close properly?

Community
  • 1
  • 1
Software_Designer
  • 8,490
  • 3
  • 24
  • 28