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

SharpCompress hangs when tar contains symbolic link and is not possible to create it #464

Open
justalemon opened this issue Aug 8, 2019 · 8 comments

Comments

@justalemon
Copy link

I was currently working on one of my programs when I tried to extract a .tar.xz (you can get it from here) and the WriteEntryToDirectory call ended up hanging on a specific file:

image

Just to make sure that I didn't made a mistake on my code, I tried to extract the file with WinRAR and it warned me that it was not possible to create a symbolic link:

image

Unable to create the symbolic link C:\Users\lemon\AppData\Local\Temp\Rar$DRa13524.1044\alpine\usr\share\terminfo\l\linux
Maybe you need to execute WinRAR with administrator permissions.

Maybe SharpCompress is not handling symbolic links errors correctly?

@justalemon
Copy link
Author

justalemon commented Aug 8, 2019

Looks like this is related to either Mono or WSL/Ubuntu. On Windows you get:

SharpCompress.Common.ExtractionException: 'Entry is a symbolic link but ExtractionOptions.WriteSymbolicLink delegate is null'

@adamhathcock
Copy link
Owner

Anymore detail? Maybe this is a simple bug? I use a MacOS so I haven't tried to reproduce this.

@RealOrko
Copy link

Just found the same thing using v0.25.0 on Fedora 31.

SharpCompress.Common.ExtractionException: Entry is a symbolic link but ExtractionOptions.WriteSymbolicLink delegate is null
   at SharpCompress.Common.ExtractionMethods.WriteEntryToFile(IEntry entry, String destinationFileName, ExtractionOptions options, Action`2 openAndWrite)

By settings up the options as follows it stopped throwing an exception:

var opt = new ExtractionOptions {
   ExtractFullPath = true,
   Overwrite = true,
   WriteSymbolicLink = (source, target) => {} 
};

After doing a little investigation it would seem there is no clear way of dealing with this in the DOTNET Runtime until this issue is solved.

@adamhathcock
Copy link
Owner

Added default delegate in https://www.nuget.org/packages/sharpcompress/0.25.1

@RealOrko
Copy link

@justalemon can you provide a specimen demonstrating the problem? I am currently using this library to download tars from all over github and have found it works across fedora 31/32 && ubuntu(bionic).

@RealOrko
Copy link

@adamhathcock is there any appetite to add an implementation that delegates to the OS in the absence of dotnet/runtime#24271?

@justalemon
Copy link
Author

@RealOrko I got the files from https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/ they contain entire Alpine distros using symbolic links.

@RealOrko
Copy link

RealOrko commented May 24, 2020

@justalemon I downloaded and unzipped image 2479, 2478 and 2477 without any issues on fedora 32.

I extracted the archive twice:

  • Once using code here.
  • The second time using the command tar -xvf ./fx.tar.xz -C ./fx

I then did a search for the symlink from your screen shot ./alpine/usr/share/terminfo/... but there wasn't any to be found in either of the extracted archives. Are you doing anything special to try and create the symlinks in your code? Once thing to try might be running your unzipping code through a console app without a GUI just to be sure that there is nothing in the UI that is blocking the unzipping process when it reports status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants