NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

NuGet.exe pack does not error when file names collide with folder names, creating packages with odd/invalid unpacking behaviour #13273

Open vexx32 opened 8 months ago

vexx32 commented 8 months ago

NuGet Product Used

NuGet.exe

Product Version

NuGet Version: 6.8.0.131

Worked before?

No response

Impact

It bothers me. A fix would be nice

Repro Steps & Context

Attempt to pack a package with the following structure:

| package-name.nuspec
| bin/
  |- file.txt
| extensionless-file

the files' contents other than the nuspec do not matter. nuspec contents:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>package-name</id>
    <version>1.0.0</version>
    <title>test-package</title>
    <authors>author name</authors>
    <owners>author name</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Test package to check extensionless files.</description>
    <summary>Test package</summary>
  </metadata>
  <files>
    <file src="bin\*" target="bin" />
    <file src="extensionless-file" target="bin" />
  </files>
</package>

Note: if the target attribute for the extensionless file is defined as bin\ instead of bin, the resulting package simply does not contain the extensionless file at all, seemingly being skipped when packing, without any warning or errors being emitted. A package like this is not malformed, but it is missing files the user tried to include, without notifying the user of any issues.

Once the package is packed (I just used nuget pack), the package can be inspected with a tool like 7zip to note that it contains both a bin file and a bin folder. When these files are extracted onto a filesystem, things get weird, it will either give an access denied error or ask about overwriting file/folder contents, depending on the tool used to unpack the nupkg.

This was first noticed because attempting to upload a package malformed in this way causes a 500 Internal Server Error when uploading to the Chocolatey Community Repository, as it does some inspection and unpacking of uploaded packages; see https://github.com/chocolatey/home/issues/303

The expected behaviour from the user perspective is that extensionless-file is placed inside the already-defined bin folder, but the common method of defining the <file> node as src="source-file" target="target-folder" does not work in this case.

Verbose Logs

No response

donnie-msft commented 8 months ago

Reproduced only with nuget.exe (non-SDK style project): image

A dotnet pack did not generate the extensionless file at all for an SDK style project.