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

Fix for MSBuild command parser confused by Fully Qualified Path to proj files in Linux root #1894 #1954

Merged
merged 1 commit into from
Apr 13, 2017

Conversation

coderpatros
Copy link
Contributor

The FileUtilities.LooksLikeLinuxPath() only returns true if the first path
segment is a directory. This can't be true for files in the root directory
on *nix systems. This commit adds an additional check to determine if the
parameter is a file.

@coderpatros
Copy link
Contributor Author

@dotnet-bot test OSX Build for CoreCLR please

@coderpatros
Copy link
Contributor Author

@Sarabeth-Jaffe-Microsoft any chance someone can look at the OSX build failure?

I'm getting this from the console output of the build...

06:41:47 Run condition [Current build status] enabling prebuild for step [[Archive the artifacts]]
06:41:48 [_OSX_CoreCLR_prtest] $ /bin/sh -xe /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/hudson3370030304074114963.sh
06:41:48 + ./cibuild.sh --scope Test --target CoreCLR
06:41:48 Installing dotnet cli...
06:54:06 curl: (56) SSLRead() return error -9806
06:54:06 ./sdk/1.0.0-preview3-003686/Microsoft.ApplicationInsights.dll: (Empty error message)
06:54:06 tar: Error exit delayed from previous errors.
06:54:06 Restoring BuildTools version 1.0.27-prerelease-00927-05...
06:54:06 Failed to load , error: dlopen(, 1): no suitable image found.  Did find:
06:54:06 	/usr/local/lib/: not a file
06:54:06 	/usr/lib/: not a file
06:54:06 ERROR: Could not restore build tools correctly. See '/Users/dotnet-bot/j/workspace/Microsoft_msbuild/master/_OSX_CoreCLR_prtest/init-tools.log' for more details.1
06:54:06 Initializing BuildTools...
06:54:06 /Users/dotnet-bot/j/workspace/Microsoft_msbuild/master/_OSX_CoreCLR_prtest/init-tools.sh: line 122: /Users/dotnet-bot/j/workspace/Microsoft_msbuild/master/_OSX_CoreCLR_prtest/packages/Microsoft.DotNet.BuildTools/1.0.27-prerelease-00927-05/lib/init-tools.sh: No such file or directory
06:54:06 ERROR: An error occured when trying to initialize the tools. Please check '/Users/dotnet-bot/j/workspace/Microsoft_msbuild/master/_OSX_CoreCLR_prtest/init-tools.log' for more details.1

I re-triggered the build in case it was a once off.

Copy link
Contributor

@jeffkl jeffkl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution.

Please create a unit test to verify this fixes the issue.

@jeffkl
Copy link
Contributor

jeffkl commented Apr 7, 2017

@mmitche Our OS X build is failing because of a weird curl SSL issue. Do you know if anything has changed with the OS X machines lately or have any idea what could cause this?

07:50:25 curl: (56) SSLRead() return error -9806
07:50:25 ./shared/Microsoft.NETCore.App/1.0.1/System.Net.Sockets.dll: (Empty error message)

@mmitche
Copy link
Member

mmitche commented Apr 7, 2017

@jeffkl @patros Depends on what the test is. The lab that the mac machines are in is having severe network issues at the moment. Did you receive an outage notification (Vs Engineering Outage mail)

@jeffkl
Copy link
Contributor

jeffkl commented Apr 7, 2017

Did you receive an outage notification

Apparently I did, sorry I missed that. Since the action that is failing is downloading a .tar, we'll just assume its related to the network issue. Thanks!

@mmitche
Copy link
Member

mmitche commented Apr 7, 2017

@jeffkl Almost certainly. Speeds are extremely low.

@coderpatros
Copy link
Contributor Author

@jeffkl changed tack a bit to make it easier to unit test. Looks like the OSX build servers are working again too.

@@ -463,6 +463,10 @@ internal static bool LooksLikeUnixFilePath(string value)
{
return true;
}
else if (Directory.Exists(value) || File.Exists(value))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, this code is on the hot path (might get called hundreds of thousands of times on large builds). Though I don't see a way of reducing IO even further.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's pretty unfortunate, and I think it'd be worth taking a bit of extra care here.

Could the check just be even more explicit for the file-in-root situation?

if (value[0] == '/' && firstSlash == 0 && (Directory.Exists(value) || File.Exists(value)))
{
    return true;
}

Copy link
Member

@rainersigwald rainersigwald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the patch! I would like to see consideration of the super-explicit check before we decide to go with this approach.

@coderpatros
Copy link
Contributor Author

@rainersigwald @cdmihai it is a terrible check to have to do. I couldn't think of a good way around it though. I've made it more explicit as requested.

Copy link
Member

@rainersigwald rainersigwald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that this is unpleasant, but I like the impact reduction of this--the new check shouldn't be very expensive even when run a bajillion times in a build, since it'll usually short-circuit out on a nice simple int-zero check.

Thanks!

@coderpatros
Copy link
Contributor Author

Yeah, that check is wayyyy better than my original one

…oj files in Linux root (#1894)

The FileUtilities.LooksLikeLinuxPath() only returns true if the first path
segment is a directory. This can't be true for files in the root directory
on *nix systems. This commit adds an additional check to determine if the
parameter is a file.
@dnfclas
Copy link

dnfclas commented Apr 12, 2017

@patros, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.

Thanks, .NET Foundation Pull Request Bot

@coderpatros
Copy link
Contributor Author

@dotnet-bot test Windows_NT Build for Desktop please

Copy link
Contributor

@AndyGerlicher AndyGerlicher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

@rainersigwald rainersigwald merged commit 44daad2 into dotnet:master Apr 13, 2017
@rainersigwald
Copy link
Member

Thanks for the fix, @patros!

@coderpatros
Copy link
Contributor Author

You're welcome!

radical pushed a commit to mono/msbuild that referenced this pull request Apr 27, 2017
FileUtilities.LooksLikeUnixPath() only returned true if the first path
segment is a directory. This can't be true for files in the root directory
on *nix systems. This commit adds an additional check to determine if the
parameter is a file or directory in the root. Fixes dotnet#1894.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants