Jump to content



Photo

FileStream - The Process Cannot Access The File

c# filestream

  • Please log in to reply
12 replies to this topic

#1 stumper66

stumper66

    Neowinian

  • Joined: 08-January 09
  • Location: Dallas, TX, USA

Posted 13 March 2014 - 19:55

Hello, 

 

I have a file copying program and I have a custom class that utilizes a System.IO.FileSteam to copy a file to a destination computer.  For the most part it works quite well.  However I use it to copy to many remote locations.  Some of them have subpar network connections.  Every so often I'll get a server that has a unreliable network connection and it will momentarily drop off the network for a few seconds.  When this happens my FileStream breaks with the exception "The specified network name is no longer available.".  This is expected.

However the problem is after the program has waited 60 seconds it will retry the transfer.  The problem now is it can't even start because I get the error "The process cannot access the file '\\MyServer\c$\MyFile.zip' because it is being used by another process".  I'll continue to get this error indefinitely until I close the program and restart the transfer, then it is able to transfer once again.

It would appear that my source server still has a file handle open when this happens that's preventing the transfer again and closing the program releases it.  I would like to programically release the handle so I can restart the transfer automatically.

 

Here's what I've tried so far:

When the file transfer is started, I grab the FileSteam.SafeFileHandle to a variable.  When I get the above error, I've tried accessing SafeFileHandle.SetHandleAsInvalid(), SafeFileHandle.DangerousRelease() and SafeFileHandle.Close(), but I'll still get the file in use error when I retry.




#2 firey

firey

    F͎̗͉͎͈͑͡ȉ͎̣̐́ṙ͖̺͕͙̓̌è̤̞͉̟̲͇̍̍̾̓ͥͅy͓̍̎̌̏̒

  • Tech Issues Solved: 6
  • Joined: 30-October 05
  • Location: Ontario, Canada
  • OS: Windows 7
  • Phone: Android (4.1.2)

Posted 13 March 2014 - 19:58

the .Close() should do it.  Are you sure the .Close() is being run? And that your error isn't skipping the close?



#3 OP stumper66

stumper66

    Neowinian

  • Joined: 08-January 09
  • Location: Dallas, TX, USA

Posted 13 March 2014 - 21:24

To replicate the problem, I imported my DLL into powershell.  I waited for the problem to occur.  I then grabbed the SafeFileHandle.  I first tried SetFileHandleAsInvalid() then retried.  Then I tried DangerousRelease().  Finally I tried Close(), but at that point I got "Exception calling "Close" with "0" argument(s): "Safe handle has been closed".

 

Also if I just call my handle variable it shows:   IsInvalid:  False, IsClosed:  True



#4 +snaphat (Myles Landwehr)

snaphat (Myles Landwehr)

    Electrical & Computer Engineer

  • Tech Issues Solved: 29
  • Joined: 23-August 05
  • OS: Win/Lin/Bsd/Osx
  • Phone: dumb phone

Posted 13 March 2014 - 21:48

Is the filestream locked? Closing a file that has outstanding locks is undefined according to the documentation.



#5 OP stumper66

stumper66

    Neowinian

  • Joined: 08-January 09
  • Location: Dallas, TX, USA

Posted 14 March 2014 - 02:06



Is the filestream locked? Closing a file that has outstanding locks is undefined according to the documentation.

 

Some how I never thought of that.  I always assumed that when I received an exception on a FileStream.Write(...) that the filestream was hosed then.  I adjusted my code as follows:

                try
                { m_Dest.Write(m_Buffer, 0, m_CurrentBlockSize); }
                catch (IOException ex)
                {
                    //  added the section below:
                    if (m_Dest.CanWrite)
                    {
                        try
                        { m_Dest.Close(); }
                        catch { }
                    }
                    // end new section
                    HadExceptionWhileCopying(ex, true);
                    return;
                }

So far it worked in my test environment.  Will see if it works in production tomorrow.

Thanks Myles!



#6 +virtorio

virtorio

    4089 III

  • Tech Issues Solved: 11
  • Joined: 28-April 03
  • Location: New Zealand
  • OS: OSX 10.9, Windows 8.1
  • Phone: Samsung Galaxy SIII

Posted 14 March 2014 - 02:18

edit: Please ignore, misread original post.



#7 +snaphat (Myles Landwehr)

snaphat (Myles Landwehr)

    Electrical & Computer Engineer

  • Tech Issues Solved: 29
  • Joined: 23-August 05
  • OS: Win/Lin/Bsd/Osx
  • Phone: dumb phone

Posted 14 March 2014 - 23:39

^ yeah the filestream may still be valid and be locked. For that matter, it could technically be still not working (in terms of communication), but it could still be marked as locked. I was thinking of calling unlock() when I posted my response. I'm not sure why the above code would work given that canWrite should just give you the state of whether the stream is closed or not and if you call close() on an already closed stream it should work fine.



#8 OP stumper66

stumper66

    Neowinian

  • Joined: 08-January 09
  • Location: Dallas, TX, USA

Posted 15 March 2014 - 00:06

My above solution worked.

 

I dug through my existing code and it was supposed to call a close on the filestream  in the event of an error but due to a flaw in my logic it never got called.



#9 notchinese

notchinese

    Neowinian

  • Tech Issues Solved: 1
  • Joined: 04-October 12

Posted 15 March 2014 - 00:28

Is it feasible given the code design to just wrap the filestream in a using() {} block?



#10 +snaphat (Myles Landwehr)

snaphat (Myles Landwehr)

    Electrical & Computer Engineer

  • Tech Issues Solved: 29
  • Joined: 23-August 05
  • OS: Win/Lin/Bsd/Osx
  • Phone: dumb phone

Posted 15 March 2014 - 02:24

My above solution worked.

 

I dug through my existing code and it was supposed to call a close on the filestream  in the event of an error but due to a flaw in my logic it never got called.

I see, that definitely fits the bill for the error you were getting!



#11 Eric

Eric

    Neowinian Senior

  • Tech Issues Solved: 11
  • Joined: 02-August 06
  • Location: Greenville, SC

Posted 21 March 2014 - 12:54

Is it feasible given the code design to just wrap the filestream in a using() {} block?

 

"using" is an assurance that Dispose() will be called to free resources. It doesn't necessarily call Close(). try...finally would do that.



#12 Andre S.

Andre S.

    Asik

  • Tech Issues Solved: 10
  • Joined: 26-October 05

Posted 21 March 2014 - 21:17

"using" is an assurance that Dispose() will be called to free resources. It doesn't necessarily call Close(). try...finally would do that.

Yes it does. http://stackoverflow...nd-stream-flush

 

In general, if an object implements Dispose() then you can expect that calling that is enough to clean it up properly, whatever the state it was in.

 

Also, using actually expands to try-finally so it's strictly equivalent, if all you're doing in the finally clause is to call Dispose().



#13 +snaphat (Myles Landwehr)

snaphat (Myles Landwehr)

    Electrical & Computer Engineer

  • Tech Issues Solved: 29
  • Joined: 23-August 05
  • OS: Win/Lin/Bsd/Osx
  • Phone: dumb phone

Posted 21 March 2014 - 21:29

^ Just to note, that documentation for Streams notes the dispose method closing the stream also:

 

http://msdn.microsof...(v=vs.110).aspx

http://msdn.microsof...(v=vs.110).aspx