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

Fix long names (GNUTYPE_LONGNAME) #389

Closed
wants to merge 2 commits into from

Conversation

frederikbosch
Copy link

The patch suggested by @RazerM in #369 is fixing my problem of a truncated file name during extraction. In my case the long file names ended up in the root of the extraction directory rather than the sub-directory they have in the archive.

I'm also not sure what the best way forward is for handling this is. I can't find anything about why these bytes might be different than expected, if not just a mixup of \0 and 0.

Is what @RazerM said last week. I'll be honest here: I don't have a clue at all. I'm just creating a PR for the solution that is solving my problem.

@RazerM
Copy link

RazerM commented Nov 12, 2024

To be clear, the issue is not related to long links.

P.S. I did not submit this as a PR myself because it should probably not be part of is_ustar – the header in the problematic tar files is non-standard.

@frederikbosch
Copy link
Author

frederikbosch commented Nov 12, 2024

Are you sure about that @RazerM? In my case, I am creating archives in exactly the same manner. The only difference is the length of the added paths. I had a look in my archiving library that I created a long time ago. It contains a specific ././@LongLink case for files with dirnames longer than 155 bytes or filenames longer than 100 bytes. And your code is a solution.

@RazerM
Copy link

RazerM commented Nov 12, 2024

The long links are stored in a header whose version bytes are "wrong", tar-rs does not look in invalid headers.

I am creating archives

Using what? Sounds like it's creating out of spec headers.

@frederikbosch
Copy link
Author

Apparently, I am using GNUTYPE_LONGNAME, see the link to my archive generation code in the message above, which is supported by Python.

@frederikbosch frederikbosch changed the title Fix long links Fix long names (GNUTYPE_LONGNAME) Nov 12, 2024
@RazerM
Copy link

RazerM commented Nov 12, 2024

I mean what program or library are you using to create the archive

@frederikbosch
Copy link
Author

frederikbosch commented Nov 12, 2024

See this library, the link references the specific line that is using the GNUTYPE_LONGNAME (L type header).

@RazerM
Copy link

RazerM commented Nov 12, 2024

I glossed over the link the first time because it's called TarReader. In any case I'm not going to review it. The library should be creating a valid header with the correct magic bytes and version.

@frederikbosch
Copy link
Author

Maybe you are right, this is not about longname.

@frederikbosch
Copy link
Author

Thanks for waking me up. I have fixed the ustar version issue in my own library. Much appreciated.

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

Successfully merging this pull request may close these issues.

None yet

2 participants