What's wrong when 'the requested operation cannot be performed on a file with a user-mapped section open?'

Question

I'm developing an application that is reading and writing a lot (but synchronously, though) to a certain file on disk. However, how larger the file gets, the more often I get the following IOException:

The requested operation cannot be performed on a file with a user-mapped section open.

occuring from:

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)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.StreamWriter.CreateFile(String path, Boolean append)
   at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
   at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding)
   at System.IO.File.WriteAllText(String path, String contents, Encoding encoding)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at TestApp.Program.Main()

As you can see, the exception is thrown from within File.WriteAllText. I suspected the exception had to do with simultaneous reading and writing, so tried to limit access to the file. Both a lock and a Mutex seemed to increase the number of exceptions instead of preventing them. So what's exactly going on? What does this exception exactly mean and how can it be prevented?

Answer 1

Does this still happen even with only one thread/process?

If so, it's not a threading issue.

If not, then you might not be using the mutex/lock correctly. Maybe you should post the relevant code here.

Answer 2

Do you have real time virus scanning software enabled?

I've lost count of the number of times file locking issues have turned out to be caused by virus scanning software.

Answer 3

I've seen this message when the Visual Studio debugger gets in a knot and locks the PDB file.

That may not be relevant to your situation, but you can confirm if the file is locked (and what by) by using a downloadable utility called "Unlocker" which can detect and remove locks on files and folders.

Answer 4

The first solution will be to turn off your antivirus. Better still you can add the folder to the scan exception list of your antivirus.

Answer 5

I was writing to a file (open,loop(writes),close) but after a mistake a duplicated the call to the rutine... so I end up with "The requested operation cannot be performed on a file with a user-mapped section open."! Well, I deleted the second call and then the problem solved. It seems that two (open/close) (open/close) rutines over the same file happening too soon one after another causes this... Some developers suggest to call the gc. Check for closing correctly every i/o operation. Not to perform complete (open,loop(writes),close) too soon. It seems that when one operation it is going to be finished while the second request arrives and that throws the problem.

Answer 6

To me, that sounds like you have some other process that opens all modified files with permissions that mean you cannot open it for modification. This could be antivirus, online backup, online file sync...