>>/9903/
Next thing to move to cold storage:
magnet:?xt=urn:btih:16bab76f8fde6732aeeca6132d7a4770f4b80189&dn=bronibooru
&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce

 >>/9883/
> How
hex->dec:
> $ printf "%d" "$((16#f))"; echo
> 15
> $ printf "%d" "$((16#30260))" # ff=255 and fff=4095
> 197216

 >>/9903/
> file carving by doing...
Inefficient, didn't use "tail --bytes=+n" which starts at byte specified by integer n.

> 7Z being weird
Without using binwalk and stuff, I'm surprised there isn't an easy way to extract files from a 7Z file which has zero compression and was partially copied. It would be harder to do if the .7z had compression. TAR is easier. With a tarball, such as "./bronibooru/s3.tar", it starts at plain text file path bytes (usually human-readable). TAR has some bytes to separate each file/folder, and .tar ends in 2904 binary zeros from what I saw. Why use ZIP instead of TAR? Because .zip has an index and .tar doesn't. This matters more if there's many files and the final tar ends up being like 80 GB. Not having an index doesn't matter with small tarballs. https://desuarchive.org/g/thread/99548793#99574085
> Is .tar really still the archive king?
No
> It obviously works and is a well-known standard, but the fact that it lacks indexing seems like a major limitation.
It is a major limitation due to less immediate usability (could use tarindexer, but still a pain).
> Is there a common alternative to .tar that preserves Unix metadata but has indexing, and maybe other features?
Does ZIP not preserves Unix metadata? Maybe TAR saves file permissions and ZIP doesn't, IDK. ZIP timestamps are not sub-second, but that info can be gained from running stat on the files and saving that metadata to a text file.