Change octal encoding in header

[JogoJogo]

Hello,

I had compatibility problems with tar files generated by the node-tar library.
In my case the archives were sent on proprietary embedded hardware, so it's quite specific.
On the other hand, the same archive generated with 7-zip or GNU tar worked perfectly. After observing the differences in the archives generated, it turned out that the significant difference was the way the numbers were encoded in the header.

This point has already been covered in ticket #28.

My pull request corrects my specific problem and outputs archives encoded in the manner of 7-zip and GNU tar.

Hope this can help

[isaacs]

To even consider this, I would need a test case that fails without the patch, and passes with it.

At the absolute least, give me steps to reproduce whatever problem it is that you're encountering. This library is used extremely widely by many many node users, as it's the tar library that npm uses. I can't change something so subtle and deep in its behavior without extremely thorough examination of the side effects and very strong justification. Its current behavior matches bsdtar, and in my experience so far, I've never seen any problems unpacking node-tar's archives using any version of gnutar made in the last 10 years or more.

I'm not trying to be difficult, but you have no idea how much difficulty it would cause to be overly casual about stuff like this.

[JogoJogo]

Hello,
Thank you for taking the time to look into this issue.

Unfortunately, in my case it's going to be extremely difficult to provide a strong justification for solving the problem.
To clarify, I'm using your library to automate the compression of a web interface bundle via vite in a tar archive. This tar archive is then loaded onto a proprietary microcontroller (Hilscher NetX 90). This microcontroller has two cores, one with a proprietary program for managing communication via industrial protocols, and another free for user applications. The proprietary part includes a web server that uses this tar archive. This is a very specific use case.
The tar archive without the modification is not recognized by the web server, so the solution in my case was the proposed modification.

I asked for it to be added because I'm not the only one (see ticket #28) and with the modification the archive is in the same form as what can be obtained with GNU tar or even 7-zip. And I agree with you, I don't have any problems with archives on a system other than the Hilscher web server either.
My understanding of the problem:

• either this type of coding is correct and just not supported in the library used by the embedded Hilscher web server.
• or the headers are incorrectly coded by your package, but almost all tools are tolerant of this error.

According to my research, in a tar archive, digits are encoded in octal and terminated by a NULL or sometimes a space (https://mort.coffee/home/tar/). Your implementation adds both. Which is perhaps a good and smart way of being ultra-compatible.

I understand that this package is a brick on which the entire node ecosystem depends, and I understand if you prefer not to change anything.
Still, I was very annoyed to notice that I had no problems with GNU tar or 7-zip and that not a single package on npm worked (they're all based on your implementation). I went through all the options before deciding to examine the archives in a hexadecimal editor.
I forked your package for my specific use, which is fine for me.
Maybe an option to configure this encoding can be a good idea so that someone who has the same problem as me can troubleshoot more quickly?

In any case, thanks for your work.

[isaacs]

I'd accept a patch to make the null/space padding configurable. Closing this, though, because changing it in the proposed manner is too risky.