Bug 15093 - Sharing violation on path
Summary: Sharing violation on path
Status: RESOLVED DUPLICATE of bug 12337
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 7.4.x
Hardware: PC Mac OS
: High normal
Target Milestone: (C7)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-10-01 09:38 UTC by Wil Laan
Modified: 2016-01-13 19:58 UTC (History)
15 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED DUPLICATE of bug 12337

Description Wil Laan 2013-10-01 09:38:51 UTC
Description of Problem:
compile error: Sharing violation on path

Steps to reproduce the problem:
1. compile source
2. 


Actual Results:

I get this error:
Error MT2001: Could not link assemblies. Reason: Sharing violation on path /Volumes/APPDEVELOP/Keezen/KeezenIPad/obj/iPhone/AppStorePaid/mtouch-cache/PreBuild/System.Core.dll.mdb (MT2001) (Keezen Complete)
Expected Results:
..

How often does this happen? 
Always

Additional Information:
This volume is MS-DOS FAT32 formatted
Comment 1 Prashant manu 2013-11-21 02:17:35 UTC
@Will, Could you provide Project for which you are observing this error or could you provide full steps so that I can reproduce this issue at my end?
Comment 2 Narayan Sainaney 2014-01-05 13:27:17 UTC
I am having this problem as well (and my partition is FAT32 as well)

I have a dual boot MacBook Pro (Windows 8/Mavericks) and the code lives on a shared FAT32 partition so I can access it from both OSes.
Comment 3 Narayan Sainaney 2014-01-05 18:18:59 UTC
I moved the project to the Macintosh HD partition (instead of the extFat partition) and the code compiled fine.
Comment 5 Tim 2014-09-18 11:07:15 UTC
I get the same issue as Narayan Sainaney.  I create a new solution on a FAT32 drive (which is a secondary drive) and the error is produced 100% of the time.
Comment 8 Brendan Zagaeski (Xamarin Team, assistant) 2014-11-24 23:38:55 UTC
## Partial workaround

In case it's helpful for anyone hitting this issue, note that you can partially work around the issue by changing the location of the `obj/` folder so that it is written to a non-FAT drive.


For example, for the "Debug|iPhone" configuration, you could open the `.csproj` file in a text editor and add the following line anywhere within the `<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|iPhone' ">` element:

> <IntermediateOutputPath Condition=" '$(OS)' == 'Unix' ">\Users\macuser\IntermediateOutput\iPhoneApp1\obj\iPhone\Debug</IntermediateOutputPath>

(Note: remove the > greater-than character from the beginning of the line.)


You can use this element to change the output path of the `obj/` folder to any HFS+ formatted location you like. After redirecting the `obj/` folder to my user folder (`/Users/macuser/`), I was able to build and run the Xamarin.iOS project stored on a FAT-formatted drive.


The `Condition=" '$(OS)' == 'Unix' "` conditional will ensure that this special `obj/` output path is _not_ used when building via Visual Studio on Windows (see [1]).

> [1] http://www.mono-project.com/archived/porting_msbuild_projects_to_xbuild/
Comment 9 Jeffrey Stedfast 2014-11-25 12:10:18 UTC
Not sure if this is fixable in the BCL, but it's certainly not fixable from Xamarin Studio.
Comment 11 Jeffrey Stedfast 2015-07-23 16:12:10 UTC
Does this happen only after debugging the app? If so, perhaps the mdb file is still open by either your app (well, the runtime that is running your app in a Simulator?) or by Xamarin Studio if it had to open the mdb file.
Comment 12 Jeffrey Stedfast 2015-07-23 16:18:58 UTC
Probably worth using lsof to figure out which process has the .mdb file open.
Comment 13 PJ 2015-08-17 14:24:41 UTC
Looks like Jeff needs more info for this one. Changing to NEEDINFO. 

Missed freeze deadline for C5SR4, moving to C6.
Comment 14 GouriKumari 2016-01-12 22:28:09 UTC
Moving the milestone to C7.
Comment 15 Sebastien Pouliot 2016-01-13 19:58:29 UTC
merging with another FAT FS issue

*** This bug has been marked as a duplicate of bug 12337 ***