• 0

FileStream - The Process Cannot Access The File


Question

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.

12 answers to this question

Recommended Posts

  • 0

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

  • 0
  On 13/03/2014 at 21:48, snaphat (Myles Landwehr) said:

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!

  • 0

^ 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.

  • 0
  On 15/03/2014 at 00:06, stumper66 said:

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!

  • 0
  On 15/03/2014 at 00:28, notchinese said:

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.

  • 0
  On 21/03/2014 at 12:54, Eric said:

"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.com/questions/911408/does-stream-dispose-always-call-stream-close-and-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().

  • 0
This topic is now closed to further replies.
  • Posts

    • I've got a basic black and white laser printer that's connected via USB and doesn't do wifi etc. I think I'm going to be just fine.
    • Edge 138 is out with AI-powered history search and other changes by Taras Buria Microsoft has released Edge 138, the latest major update for the browser. Version 138.0.3351.55 introduces some interesting changes and new features, such as AI-powered history search. There are also several bug fixes and security patches. For regular users, the biggest and most important change in Edge 138 is AI-powered history search. This feature allows you to find sites in your history using synonyms, phrases, or misspelled words. Microsoft uses an on-device model, which does not send your data anywhere. Note that this feature is rolling out gradually, which means it might take a few days or weeks to show up on your system. Another useful change is new performance notifications. Performance and Extensions Detector notifications may appear in the main menu when the browser detects performance dips to help users learn about available performance-optimization tools. Autofill settings received a new consent toggle, which allows Microsoft to improve the autofill capabilities by collecting field names as you browse. This only applies to field names, such as "First Name, "Email," etc. It does not send the data you enter or autofill to Microsoft. Other changes include the following: Use the Primary work profile as the default profile to open external links. With this feature, for Windows, Edge checks if the Primary Work Profile exists and makes it the default profile for opening external links if available. Microsoft 365 Copilot Chat Summarization in Microsoft Edge Context Menu. This feature helps users quickly unpack and ask questions about their open page. Copilot on the Microsoft Edge New Tab Page (NTP). Users may see suggested work and productivity-related Copilot prompts in their search box on the NTP page. Adding support for viewing Sensitivity labels applied to a Microsoft Information Protection (MIP) Protected PDF. Enterprise customers can view sensitivity labels applied to MIP protected PDF to be well informed of the data classification to enable them to handle such sensitive documents. And here is what was fixed: Fixed an issue that caused WebDriver automation to fail in Microsoft Edge versions 133 and later. Fixed an issue where re-enabled textarea elements remained non-editable. This issue affected activating a role assignment in Privileged Identity Management. Finally, Edge 138 patches six security vulnerabilities, three of which were Microsoft Edge-specific, and the remaining three originated from Chromium. You can find details about those fixes here. The next Microsoft Edge update, version 139, is expected in the week of August 7, 2025.
    • “Never trust any statistics that you didn't forge yourself.”
    • Per the linked article: "Based on testing performed by Microsoft in December 2024 using Geekbench 6 Multi-core score comparing a selection of Windows 10 PCs with Intel Core 6th, 8th, and 10th generation processors and Windows 11 PCs with Intel Core 12th and 13th generation processors." I get that this is just advertising and all, but damn, I can smell the BS all the way over here. How about benchmarking 10 vs 11 on that same 13th gen processor? Apples and oranges make a lovely fruit salad but a terrible comparison. I mean shoot, my Windows 10 PC running a Ryzen 7 is faster than a Core2Duo running Windows 7, so Windows 10 is clearly faster. 🙄
    • KB5060829 installed in a test VM and the option isn't even there under "Taskbar behaviours". Installed it on a second VM, same. Installed it on metal... same. Typical quality of Nadella's Microsoft. If i doesn't shrink the taskbar vertical height down as @seeprime is implying, what's the point?
  • Recent Achievements

    • Week One Done
      suprememobiles earned a badge
      Week One Done
    • Week One Done
      Marites earned a badge
      Week One Done
    • One Year In
      runge100 earned a badge
      One Year In
    • One Month Later
      runge100 earned a badge
      One Month Later
    • One Month Later
      jfam earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      562
    2. 2
      +FloatingFatMan
      177
    3. 3
      ATLien_0
      167
    4. 4
      Michael Scrip
      125
    5. 5
      Xenon
      121
  • Tell a friend

    Love Neowin? Tell a friend!