dotnet migrate fails on Linux if app directory is directly under a folder with a cyclic symlink
See original GitHub issuedotnet migrate
fails on Linux if the app directory is directly under root (e.g. /app
). It’s easy to repro with docker containers, but it should also repro on the host OS.
It repros when using microsoft/dotnet-nightly:1.1.0-sdk-msbuild-rc4
or later. It works fine when using microsoft/dotnet:1.1.0-sdk-msbuild-rc3
.
It also works fine if the app directory is two levels below root (e.g. /src/app
).
Steps to reproduce
mkdir ~/new
docker run -it --rm -v ~/new:/new microsoft/dotnet:1.1.0-sdk-projectjson
cd new
dotnet new
exit
docker run -it --rm -v ~/new:/new microsoft/dotnet-nightly:1.1.0-sdk-msbuild-rc4
cd new
dotnet migrate
Expected behavior
App is migrated from project.json to MSBuild.
Actual behavior
dotnet migrate
will either hang or throw the following exception:
root@08dd3e787323:/new# dotnet migrate
Migration failed.
Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/fd/78'.
at System.IO.UnixFileSystem.FileSystemEnumerable`1.OpenDirectory(String fullPath)
at System.IO.UnixFileSystem.FileSystemEnumerable`1.<Enumerate>d__11.MoveNext()
at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source, Int32& length)
at System.IO.DirectoryInfo.InternalGetDirectories(String searchPattern, SearchOption searchOption)
at System.IO.DirectoryInfo.GetDirectories(String searchPattern, SearchOption searchOption)
at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.GetPotentialProjects(IEnumerable`1 searchPaths)
at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.FindPossibleProjectDependencies(SlnFile slnFile, String projectJsonFilePath)
at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.ResolveDirectProjectDependenciesForFramework(Project project, NuGetFramework framework, IEnumerable`1 preResolvedProjects, SlnFile solutionFile)
at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.ResolveAllProjectDependenciesForFramework(ProjectDependency projectToResolve, NuGetFramework framework, IEnumerable`1 preResolvedProjects, SlnFile solutionFile)
at Microsoft.DotNet.ProjectJsonMigration.Rules.MigrateProjectDependenciesRule.MigrateProjectJsonProjectDependency(Project project, NuGetFramework framework, HashSet`1 migratedXProjDependencyNames, SlnFile solutionFile, ProjectRootElement outputMSBuildProject)
at Microsoft.DotNet.ProjectJsonMigration.Rules.MigrateProjectDependenciesRule.MigrateProjectJsonProjectDependencies(IEnumerable`1 projectContexts, HashSet`1 migratedXProjDependencyNames, SlnFile solutionFile, ProjectRootElement outputMSBuildProject)
at Microsoft.DotNet.ProjectJsonMigration.Rules.MigrateProjectDependenciesRule.Apply(MigrationSettings migrationSettings, MigrationRuleInputs migrationRuleInputs)
at Microsoft.DotNet.ProjectJsonMigration.DefaultMigrationRuleSet.Apply(MigrationSettings migrationSettings, MigrationRuleInputs migrationRuleInputs)
at Microsoft.DotNet.ProjectJsonMigration.ProjectMigrator.MigrateProject(MigrationSettings migrationSettings)
at Microsoft.DotNet.ProjectJsonMigration.ProjectMigrator.Migrate(MigrationSettings rootSettings, Boolean skipProjectReferences)
at Microsoft.DotNet.Tools.Migrate.MigrateCommand.Execute()
at Microsoft.DotNet.Tools.Migrate.MigrateCommand.<>c__DisplayClass35_0.<Run>b__0()
at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.DotNet.Tools.Migrate.MigrateCommand.Run(String[] args)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)
Aborted (core dumped)
Environment data
dotnet --info
output:
.NET Command Line Tools (1.0.0-rc4-004757)
Product Information:
Version: 1.0.0-rc4-004757
Commit SHA-1 hash: f69f0ed266
Runtime Environment:
OS Name: debian
OS Version: 8
OS Platform: Linux
RID: debian.8-x64
Base Path: /usr/share/dotnet/sdk/1.0.0-rc4-004757
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Dotnet CLI fails building after mv to other directory?
I've tried them seperately and found out that the 'dotnet build' command gives the error. The git repo was completely empty, I just...
Read more >Too many levels of symbolic links
Use the absolute path instead of the relative path, then it will work. Eg: ln -s /home/user/test/src /home/user/test/firefox.
Read more >What happens to a symbolic link when the original file is ...
I have update software in /opt/minergate-cli . I've renamed the directory minergate-cli to minergate-old with an mv command, then installed a ...
Read more >How do I resolve a "Too many levels of symbolic links ...
I am using the latest Deepin 15.11, and have just discovered that I cannot access my Documents folder (/home/username/Documents).
Read more >FAQ — Syncthing documentation
Does Syncthing support syncing between folders on the same system? When I do have two distinct Syncthing-managed folders on two hosts, how does...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks, that worked. I will update this issue with the correct root cause:
dotnet migrate
fails if the app directory is at the root. This is a fairly common pattern in docker containers (e.g. see the instructions at https://hub.docker.com/r/microsoft/dotnet/).Ok, I understand why this happens. This happens because you created your new project at the root of the docker machine. If you create something like src/new and then put your project there, it will work.
Migration looks at the parent folder you are migration migration at, in this case / so that it can find dependencies for your project, which is why we are hitting this issue.
We had to add the GetDirectories call with SearchOptions.AllDirectories so that we could actually find dependencies for a project that were deeper on the folder structure than the project itself.
Can you try the work around I suggested?