[Bug]: nuget.exe regression in handling of recursive <files> entries between 5.9.1 and 5.10.0

[deadalusai]

NuGet Product Used

NuGet.exe

Product Version

5.10

Worked before?

5.9.1

Impact

I'm unable to use this version

Repro Steps & Context

If I'm using a recursive src pattern and a target in 5.9.1 then it recursively recreates the directory tree inside that target folder. E.g.

<file src="some/subdirectory/**" target="lib" />

Creates something like the following:

lib/some/subdirectory/a.dll
lib/some/subdirectory/x/b.dll
lib/some/subdirectory/y/c.dll

In 5.10 it does the same but apparently only from the point in the directory hierarchy where you put the **. E.g. the same configuration creates something like the following:

lib/a.dll
lib/x/b.dll
lib/y/c.dll

The behavior in 5.10 matches the documentation of src and target currently in the .nuspec reference so this may have been a deliberate change in behavior, though I can't see anything in the 5.10 release notes about it.

This change broke our nuspec when our build server was automatically upgraded to the latest 5.* (a minor version update). We've fixed for the 5.10 behavior but our .nuspec can no longer be correctly consumed by older versions of nuget.exe. Is there a backwards-compatible workaround we can use, or is this a regression that's likely to be reverted?

Another concern is that currently nuget update -self does not install 5.10.0 so this issue may have gone unnoticed for a while (edit: this has been fixed).

This repository can be used to reproduce and visualize the change in behavior - example output below.
https://github.com/deadalusai/NuGetFilesBehaviorRepro

Verbose Logs

Testing nuget.exe 4.9.4...
NuGet Version: 4.9.4.5839
Attempting to build package from 'example.nuspec'.

Id: Example
Version: 0.0.0.0
Authors: Ben
Description: Example
Project Url: http://example.com/
Tags: example
Dependencies: None

Added file '[Content_Types].xml'.
Added file '_rels/.rels'.
Added file 'Example.nuspec'.
Added file 'package/services/metadata/core-properties/4bd72b7ab4a94cde8e38750f5261331b.psmdcp'.
Added file 'tools/some/subdirectory/a.dll'.
Added file 'tools/some/subdirectory/x/b.dll'.
Added file 'tools/some/subdirectory/y/b.dll'.

Successfully created package 'C:\Dev\NuGetBugRepro\output\4.9.4\Example.0.0.0.nupkg'.
Testing nuget.exe 5.9.1...
NuGet Version: 5.9.1.11
Attempting to build package from 'example.nuspec'.

Id: Example
Version: 0.0.0.0
Authors: Ben
Description: Example
Project Url: http://example.com/
Tags: example
Dependencies: None

Added file '[Content_Types].xml'.
Added file '_rels/.rels'.
Added file 'Example.nuspec'.
Added file 'package/services/metadata/core-properties/09f7b8ffe1824ac384977a289f987050.psmdcp'.
Added file 'tools/some/subdirectory/a.dll'.
Added file 'tools/some/subdirectory/x/b.dll'.
Added file 'tools/some/subdirectory/y/b.dll'.

Successfully created package 'C:\Dev\NuGetBugRepro\output\5.9.1\Example.0.0.0.nupkg'.
Testing nuget.exe 5.10.0...
NuGet Version: 5.10.0.7240
Attempting to build package from 'example.nuspec'.

Id: Example
Version: 0.0.0.0
Authors: Ben
Description: Example
Project Url: http://example.com/
Tags: example
Dependencies: None

Added file '[Content_Types].xml'.
Added file '_rels/.rels'.
Added file 'Example.nuspec'.
Added file 'package/services/metadata/core-properties/1be895fac04f4b43b061b1983fa9881a.psmdcp'.
Added file 'tools/a.dll'.
Added file 'tools/x/b.dll'.
Added file 'tools/y/b.dll'.

Successfully created package 'C:\Dev\NuGetBugRepro\output\5.10.0\Example.0.0.0.nupkg'.

[erdembayar]

@aortiz-msft
I can repro this. Not sure if it's actually regression or no, most likely it's coming from this PR. For me old behavior looks more reasonable, need more investigation.

[aortiz-msft]

@erdembayar - Could you please validate that the linked PR is the offending change?

[erdembayar]

@aortiz-msft
I narrowed down actual offending Readme PR. It only happens after this PR.

[aortiz-msft]

@zkat - Would you please take a look?

[yufeih]

Copy my confusion from dotnet/docfx#7569, we need some clarification on the intended behavior when src is used in conjunction with target:

This syntax <file src="build/**" target="build"/> can have different interpretations:

1. If src is treated as a transparent glob pattern, then the glob matcher for build/a.txt yields build/a.txt and place it at build/build/a.txt like the behavior in 5.9.1
2. If NuGet tries to remove common prefix using the target attribute, then the glob matcher for build/a.txt yields build/a.txt and then turn it into a.txt before placing it to build/a.txt, like the behavior in 5.10.0
3. If NuGet tries to be really clever and look for ** in the glob pattern, then the glob matcher for build/a.txt yields a.txt place it at build/a.txt, like the behavior in 5.10.0. (But what does it mean for glob patterns like build/**/a** or buil?/**?)

[jeffkl]

Thanks for reporting this, I'm going to revert the change that caused this regression and we've added a test to catch it if it ever happens again.

NuGet/NuGet.Client#4270