HN

Comments (16)

• Menu

  Joker_vD
  > Now, POSIX says that data blocks for a hard link “may be included” in pax archives, but the implications of this are not entirely clear.How so? If the data blocks are included, then those are the intended content of the file behind that hard link. They should overwrite the previous content of the file.> So the 512 bytes after the hard link are its data, and not the header of empty as we archived it?Yes, precisely.> How can a hard link have different contents from its previous counterpart file?Why, very simply: while the archive was being created, the file behind the two different hard links changed; the archival utility noticed it, and included the new content of the file as the content for the second hard link instead of rewinding and overwriting the original file in the archive (which would be impossible to do on a tape, you know). At least I believe that's what was the rationale for this allowance, and the intended behavior on the extraction.
• Menu

  molticrystal
  >NET, Julia and uv's tar-codec - These implementations reject the tarball. I believe this is the best thing you can do, even if it's technically not POSIX-compliant.While this is the safest choice, it is the least helpful, I would always prefer to get something out of an archive then nothing. Damage/irregularity to an archive shouldn't prevent data inspection, just a warning and a way to fall back with caveats for what can be extracted.
• Menu

  bartvk
  This guy, what a hero. He even included a little graphic to show how this "hardest tarball" looks like.At the bottom, there's a link to much more edge cases.It reminds me of this beauty: "Parsing JSON is a Minefield" https://news.ycombinator.com/item?id=16897061
• Menu

  rmast
  I’ve been working on an open source tool for creating SBOMs from binaries/file systems. Automated extraction of archives like zip/tar files present interesting challenges - for a while I’ve known about OS filesystem formatting gotchas like archives from a Linux-based system with symlinks or case colliding names not extracting correctly on NTFS (and HFS+ for the latter case).But the ambiguity of this tar files… I guess the “correct” extraction for what I’m doing would require figuring out what the system that is processing the tar files used and copy that behavior, which is non-trivial if you don’t know what an embedded device is using behind the scenes.
• dataflow
  Disregarding erroring as an option-I feel like the most faithful extraction would dictate that any field in the original header should take precedence over the PaxHeader's iff the PaxHeader field's value would've been representable in the original field. Anyone have thoughts?
• Menu

  djha-skin
  Tl;dr don't use pax.Hit up Wikipedia for tarball format and you may agree with me. It's a classic example of a standard where you look at it and go, "??? Who asked for that?". I'm not surprised the article focuses on pax when finding tar inconsistencies. Original tar is just fine.
• bahung1221
  [flagged]