locked
Error The system cannot open the file. RRS feed

  • Question

  • Hi All,

    I'm reading the content of a file as follows.

    using(StreamReadertr = newStreamReader(aFile.Path))

    {

                        builder.Append(tr.ReadToEnd());

                        tr.Close();

    }

    And at random I get the following exception message. "Error The system cannot open the file."

    The innter excpetion is blank.

    What's the best way to get more information on this \ the exact windows IO error.

    Thanks

    Warrick

    Tuesday, June 5, 2012 7:42 PM

Answers

  • yeah, try reading with something other than StreamReader ... that will certainly be interesting.

    OK, so we've determined that the path is valid, the file exists, it is probably not a security issue ... so I think we're back to the issue of someone or something has the file open briefly for updates or whatever.  Is it possible that you are competing with someone or some other machine for access to the file?

    Here's something to try ... when you catch the exception, place the troublesome pathname on a list and resume processing with the next name.   Then, anytime after waiting some reasonable period of time, try again to access the file designated by the pathname that had previously failed.   It may be that someone or someTHING had the file open when you tried to access it.

    Our strategy is to wait a few minutes then try it again.

    interesting problem, huh ?

    bill

    • Marked as answer by Bob Shen Monday, June 18, 2012 8:26 AM
    Thursday, June 7, 2012 8:09 PM

All replies

  • Are you reasonably certain that the path you're providing is valid ?    and that the exception is being generated asa result of the code shown?

    I would try placing the statement "builder.Append(tr.ReadToEnd());" in a try-catch block, then set a breakpoint at the first statement in the catch block. When the problem reoccurs, check the path and 'builder'.

    Tuesday, June 5, 2012 7:55 PM
  • It looks like the exception is coming from 
    newStreamReader(aFile.Path)
    What's the exception type? Meaning are you getting an IOException, ArgumentException, etc.
    Tuesday, June 5, 2012 9:40 PM
  • Have you tried using any of the possible exceptions catch block, setting a breakpoint within the try block, and then stepping through to get all the information?  It could even be that you don't have permissions on that file.

      try
      {
          using(StreamReader tr = new StreamReader(aFile.Path))
          {
              builder.Append(tr.ReadToEnd());
              tr.Close();
          }
      }
      catch (FileNotFoundException ex)
      {
          string msg = ex.Message;
          string src = ex.Source;
      }
      catch (UnauthorizedAccessException ex)
      {
          string msg = ex.Message;
          string src = ex.Source;
      }
      catch (IOException ex)
      {
          string msg = ex.Message;
          string src = ex.Source;
      }
      catch (Exception ex)
      {
          string msg = ex.Message;
          string src = ex.Source;
      }
       
    Hope that helps!

    Christine A. Piffat

    Tuesday, June 5, 2012 10:24 PM
  • Ah, yes thanks guys this did get me a lot closer.

    It looks like this block is catching it.

    catch(IOException ex)

    string msg = ex.Message;
    string src = ex.Source;
    logger.Error(string.Format("A2 Error while processing {0}. Error {1}. Source {2}", aFile.Path, msg, src));

    This is the error being logged.

    ... A2 Error while processing ......O599397118.xml. Error The system cannot open the file.
    . Source mscorlib

    This is running under IIS 6 and the application pool has admin rights.

    What's strange though is tha the problem is not consistent. The process runs through 1000's of files and if I re-run the process it doesn't seem to choke on the same file every time. I should not that this is a highly threaded application though.

    Thanks
    Warrick


    Wednesday, June 6, 2012 12:33 PM
  • According tto MSDN Documentation (http://msdn.microsoft.com/en-us/library/f2ke0fzy) IOException is the result of:

    IOException

    path includes an incorrect or invalid syntax for file name, directory name, or volume label.

    Could it be that under some circumstancing the aFile.Path is malformed? Not sure how that could be but it seems that the error output here was edited. Try cutting and pasting aFile.Path from your errorlog to File explorer and make sure it opens the file... I know it's reaching but nothing else comes to mind. That's assuming there's no inner exception listed. Could be that the error is coming from the underlying stream.. but it doesn't look like it from the description you've put forth here.


    Wednesday, June 6, 2012 3:37 PM
  • No, I double check that and that doesn't seem to be a problem. It's a network path so didn't want to share the internal structure.

    To make matters more confusiong I don't seem to be able to reproduce the problem when running this as a console application.

    Next step I think I'll try running process monitor while it's running and see if that points out anything specific.

    Wednesday, June 6, 2012 5:28 PM
  • What are the conditions to read the file? Are you using a timer function or a filewatcher or something like that?
    Wednesday, June 6, 2012 5:32 PM
  • Admin rights aren't really relevamt if the path is to another machine that:

    1) The user doesn't actually have access to because the account has no access rights to that other machine, assuming that impersonation of that user is really happening at the time you get the error.

    2) Is a mapped drive that is not visible because impersonation of a user does not usually load that user's profile, so that mapped drive will not be visible.


    Phil Wilson

    Wednesday, June 6, 2012 7:25 PM
  • It might be instructive to capture a failing pathname from inside the Catch block, then attempt to create a FileInfo class predicated on that path name.

    The FileInfo class constructor will throw an exception if there is a security problem or the path is too long (or several other probably-irrelevant conditions). If the FileInfo does NOT throw an exception, reference the FileInfo.Exists property with the failing path. Let's see if the file exists.   If that succeeds, try gtting the FileAttributes via the FileInfo.Attributes property.

    Wednesday, June 6, 2012 7:27 PM
  • The best way to debug this is with WINDBG, and or ADPLUS.  ADPLUS can listen for an exception and perform a mini-dump at which time you can see everything you need using WINDBG.

    JP Cowboy Coders Unite!

    Wednesday, June 6, 2012 10:39 PM
  • This was an interesting test and idea.

    I put the following into the catch:

                        FileInfo zInfo = new FileInfo(aFile.Path);
                        logger.Info(string.Format("A3 Info for {0} file size {1}", aFile.Path, zInfo.Length));
    
                        if (File.Exists(aFile.Path))
                        {
                            FileAttributes zAttrib =  zInfo.Attributes;
                            logger.Info(string.Format("A3 Attributes for {0} ToString {1}", aFile.Path, zAttrib.ToString()));
                        }
                        else
                        {
                            logger.Info(string.Format("A3 exists for {0} file failed", aFile.Path));
                        }
    
    So I got the usual exception ..

    Error while processing .............\670\208\O670208064.xml. Error The system cannot open the file.
    . Source mscorlib, Inner xx, Stack    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
       at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)
       at System.IO.StreamReader..ctor(String path)

    But the following was then also logged.

    Info for .....670\208\O670208064.xml file size 6264

    And

    .....670\208\O670208064.xml ToString Archive, NotContentIndexed

    So event tough the exception was thrown it was able to check that the file existed and I was able to get the attributes of the file.

    Thursday, June 7, 2012 4:04 PM
  • ok, thanks, I'll try WINDBG, and or ADPLUS next. Have not used them before so looks like this could be a project in itself.
    Thursday, June 7, 2012 4:08 PM
  • Interesting results ...

    Apparently the path is valid and the file exists.   As someone asked much earlier, I wonder if this could be a security issue.

    Since you know that you can create a FileInfo instance on the filename, and can do a fileInfo.GetAttributes, I'd follow that with a zInfo.Open(FileMode.Open, FileAccess.Read)

    This is likely to fail as well, but the exception it throws includes SecurityException and UnauthorizedAccessException. Either of those exceptions would tell us that this is a security issue.   AND, if you get an IO Exception, that suggests that the file is already open.

    http://msdn.microsoft.com/en-us/library/dzdw7xcy


    • Edited by Lincoln_MA Thursday, June 7, 2012 4:39 PM
    Thursday, June 7, 2012 4:29 PM
  • Ha, no, this is wild. It opened just fine.

                        FileInfo zInfo = new FileInfo(aFile.Path);
                        logger.Info(string.Format("A3 Info for {0} file size {1}", aFile.Path, zInfo.Length));
                        FileStream zStream = zInfo.Open(FileMode.Open, FileAccess.Read);
                        logger.Info(string.Format("A3 Info for {0} file OPENED", aFile.Path, zInfo.Length));
                        zStream.Close();

    The log after zInfo.Open worked just fine...

    Very strange. Perhaps try reading with something other than StreamReader?

    Thursday, June 7, 2012 5:52 PM
  • yeah, try reading with something other than StreamReader ... that will certainly be interesting.

    OK, so we've determined that the path is valid, the file exists, it is probably not a security issue ... so I think we're back to the issue of someone or something has the file open briefly for updates or whatever.  Is it possible that you are competing with someone or some other machine for access to the file?

    Here's something to try ... when you catch the exception, place the troublesome pathname on a list and resume processing with the next name.   Then, anytime after waiting some reasonable period of time, try again to access the file designated by the pathname that had previously failed.   It may be that someone or someTHING had the file open when you tried to access it.

    Our strategy is to wait a few minutes then try it again.

    interesting problem, huh ?

    bill

    • Marked as answer by Bob Shen Monday, June 18, 2012 8:26 AM
    Thursday, June 7, 2012 8:09 PM