3

In my program I have a chunk of code that does

var lines = File.ReadAllLines(myFileName);

if (lines[0] != null)
{
    //does a few things
    File.WriteAllLines(myFileName, lines);
}

While this worked fine at first, recently it has given me an exception due to the file being used by another process ~90% of the time. This already made no sense to me since File.ReadAllLines() is supposed to close the file after reading. I added System.Threading.Thread.Sleep(3000) right before the File.WriteAllLines(), which increased my success rate to ~50%. Is sleeping the thread and crossing my fingers really my only option? I can not find any sources where people have had similar issues with File.ReadAllLines().

Any suggestions, explanation, or practical fixes would help. I can't help but feel like I'm missing something.

EDIT: edited my if statement with the actual code, incase it matters

EDIT: I am reading and writing the file to a network share, not my local machine.

EDIT: It does not appear to be any kind of hung version of my app holding on to the file, and from what I can tell by using the FileUtil class in this question, it is my app that has a lock on the file.

Community
  • 1
  • 1
psoshmo
  • 1,490
  • 10
  • 19
  • 4
    There shouldn't be any problem. Are you sure the file is not open elsewhere or there's not an instance of your program currently stuck in the processes list? Or maybe you ran the app in debug mode and stopped it before it could dispose of the file handle? – Pierre-Luc Pineault Aug 11 '15 at 19:18
  • 1
    I can run this without any problem, so you have an other issue: `var filename = @"C:\temp\test.txt"; for (var i = 0; i < 10000; i++) { var lines = File.ReadAllLines(filename); File.WriteAllLines(filename, lines); }` – huysentruitw Aug 11 '15 at 19:19
  • 5
    You may have an anti-virus or indexing running on that file after its being written causing the lock, its nothing to do with the framework. – Ron Beyer Aug 11 '15 at 19:23
  • @Pierre-LucPineault I edited my if statement with the actual one I am using, I doubt it makes a difference, but just incase I added it – psoshmo Aug 11 '15 at 19:24
  • @RonBeyer how would I even go about confirming that/fixing it? – psoshmo Aug 11 '15 at 19:24
  • 2
    You may want to try using a FileStream opened with ReadWrite access and perform the entire operation yourself in order to have better control over the file access. Don't forget to call .Flush() if you do. – Martin Noreke Aug 11 '15 at 19:25
  • Turn off your antivirus, run the test. Also you can go into the services and shut off indexing. As far as fixing it, I'm not sure, you may have to loop while trying to open the file until you time out or it opens. Otherwise write to a temporary file and copy over the old one when its available. – Ron Beyer Aug 11 '15 at 19:25
  • @psoshmo: Perhaps you can catch the lock exception then use an answer [from here](http://stackoverflow.com/questions/317071/how-do-i-find-out-which-process-is-locking-a-file-using-net) to figure out what process is locking the file. – Chris Sinclair Aug 11 '15 at 19:25
  • 1
    You could check which processes are accessing the file via [Process Explorer](https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx). – Anssssss Aug 11 '15 at 19:28
  • When it happens, you can use a program like `Unlocker 1.9.2` to check what's the process currently using your file (And potentially unblock it). So you'd be able to know if it's your AV, your app or something else. – Pierre-Luc Pineault Aug 11 '15 at 19:32
  • @Pierre-LucPineault I checked using the FileUtil class that ChrisSinclair linked me to, and it is indeed my app locking it. Which leaves me right back where I started :( – psoshmo Aug 11 '15 at 19:33
  • @ChrisSinclair if it were indexing or anti virus causing the lock, I assume the process thats locking it wouldnt show as my app? – psoshmo Aug 11 '15 at 19:34
  • 2
    Here is the function if you want to see how it works: http://referencesource.microsoft.com/#mscorlib/system/io/file.cs,675b2259e8706c26 Once it exits the `using` scope, `Dispose` is called on the `StreamReader` which should be closing the file immediately. Its not an asynchronous method so it shouldn't be returning before `Dispose` has finished doing its work. – Ron Beyer Aug 11 '15 at 19:42
  • @psoshmo: Do you have a hung version of your application still running in the background? Also, just a stab in the dark, are you trying to read/write files to some external source (like a network share) other than a local hard drive? – Chris Sinclair Aug 11 '15 at 19:47
  • @ChrisSinclair I AM reading and writing from a network share, sorry I shouldve included that in the original question (its been one of those afternoons). I am currently testing to see if there is a hung version, Ill get back to you on that. – psoshmo Aug 11 '15 at 19:55
  • @ChirsSinclair there are no hung versions of my app. Perhaps it could be the antivirus on the server? – psoshmo Aug 11 '15 at 19:59

1 Answers1

0

I have figured out what the issue was. Prior to this code ever being reached, there was some older "legacy" code that quickly read the file for what is now an outdated reason. A lot of the legacy code we have has very sloppy use of streams, and I have recently been going back and cleaning it up and implementing proper using() syntax wherever it wasnt being used. Apparently I missed a spot, and had an old StreamReader that was never being disposed of. Thanks to everyone for the comments, learned some things in the process.

psoshmo
  • 1,490
  • 10
  • 19