Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple instances of nuget.exe trying to install the same package in parallel causes a double write #2628

Closed
kingerja opened this issue Apr 21, 2016 · 6 comments

Comments

@kingerja
Copy link

Scenario
ProjectA and ProjectB each have a packages.config that contain the same package. They each build in parallel. Each checks that the nuget package needs to be installed at the same time and then both try to install it. (they both appear to install it fine.) However the files are written out by both instances of nuget.exe.

(the plus side is this has revealed some bad practices where teams were hard linking from nuget package folders then overwriting the hardlinked file corrupting their nuget package install.)

(The down side is build tracers like buildcop need to now have nuget.exe exclusions for double-writes and doublewriting in practice is problematic especially if projectC thinks the package is installed because it is a large package that projectA installed and projectB is still doing a doublewrite and then projectC ends up doing a read lock on a file that projectB is trying to doublewrite causing an access violation.)

perhaps a mutex or something on the package folder should be created before nuget attempts to install a package.

@rrelyea
Copy link
Contributor

rrelyea commented Apr 21, 2016

What version of nuget.exe are you using?
Likely fixed in 3.3 or 3.4, we believe.

@zhili1208
Copy link
Contributor

@kingerja I add a lock in folderNuGetProject, Can you help to validate the fix with my private build? Please ping me on skype, I can give you the build, thanks

@kingerja
Copy link
Author

Sorry for delay my DRI rotation was very eventful.
I have been unable to get a standalone repro. However I do have a consistent repro in one of the build systems I use. So I can try any private I need and set any flags you desire for additional tracing.
I have pinged you on skype let me know what bits you want me to try.

@kingerja
Copy link
Author

kingerja commented May 2, 2016

Hi I have been unable to produce a repro with this private. I have run many builds and have not hit it. Since it was a consistent repro it appears you have fixed this issue.

You may close this issue. Thanks.

@yishaigalatzer
Copy link

That's great news! @zhili1208 please include the commit on the issue before closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants