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

Tar entries should be able to handle paths that begin with "./", including the root path itself #70516

Closed
carlossanlop opened this issue Jun 9, 2022 · 2 comments · Fixed by #70853
Assignees
Milestone

Comments

@carlossanlop
Copy link
Member

carlossanlop commented Jun 9, 2022

Description

Bug found while investigating this issue: #70509

TarReader.GetNextEntry is unable to retrieve entries that have the path set to ./.

Reproduction Steps

Download https://dotnetcli.azureedge.net/dotnet/Runtime/6.0.5-servicing.22213.9/dotnet-runtime-6.0.5-osx-x64.tar.gz

string targetPath = "D:/some/destination";
using FileStream compressedStream = File.OpenRead(@"D:/path/to/dotnet-runtime-6.0.5-osx-x64.tar.gz");
using GZipStream decompressor = new(compressedStream, CompressionMode.Decompress);
TarFile.ExtractToDirectory(source: decompressor, destinationDirectoryName: targetPath, overwriteFiles: true);

Expected behavior

The archive is extracted.

Actual behavior

    System.IO.IOException : Extracting the Tar entry './' would have resulted in a file outside the specified destination directory: 'C:\Users\carlos\AppData\Local\Temp\zm5gtquh.qu5\'

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

@carlossanlop carlossanlop added this to the 7.0.0 milestone Jun 9, 2022
@carlossanlop carlossanlop self-assigned this Jun 9, 2022
@ghost
Copy link

ghost commented Jun 9, 2022

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

Bug found while investigating this issue: #70509

TarReader.GetNextEntry is unable to retrieve entries that have the path set to .\.

Reproduction Steps

Download https://dotnetcli.azureedge.net/dotnet/Runtime/6.0.5-servicing.22213.9/dotnet-runtime-6.0.5-osx-x64.tar.gz

string targetPath = "D:/some/destination";
using FileStream compressedStream = File.OpenRead(@"D:/path/to/dotnet-runtime-6.0.5-osx-x64.tar.gz");
using GZipStream decompressor = new(compressedStream, CompressionMode.Decompress);
TarFile.ExtractToDirectory(source: decompressor, destinationDirectoryName: targetPath, overwriteFiles: true);

Expected behavior

The archive is extracted.

Actual behavior

    System.IO.IOException : Extracting the Tar entry './' would have resulted in a file outside the specified destination directory: 'C:\Users\carlos\AppData\Local\Temp\zm5gtquh.qu5\'

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author: carlossanlop
Assignees: carlossanlop
Labels:

area-System.IO

Milestone: 7.0.0

@carlossanlop carlossanlop changed the title Tar entries should be able to handle paths that begin with "\.", including the root path itself Tar entries should be able to handle paths that begin with "./", including the root path itself Jun 10, 2022
@carlossanlop
Copy link
Member Author

carlossanlop commented Jun 10, 2022

The prefix ./ gets added to files when the tar command is executed with explicit addition of the ./ prefix on the individual entries to be archived:

tar -cvf target.tar ./file.txt ./directory/

This usually happens when the file is added by tabbing for autocomplete.

The prefix is not added if you use * to include all files in a location:

tar -cvf target.tar *

So to add the ./ entry to the archive (the cause of this bug), you'd have to execute the command using:

tar -cvf target.tar ./

Which would add all the files in the current directory (excluding the tar archive you're creating), will prepend the ./ prefix to all the entries, and will also include the single entry ./ at the beginning of the archive.

When you open such archive with 7-zip, it shows at the root a single directory entry named . and all the rest of the entries are under that directory.

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jun 16, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jun 17, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jul 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant