summaryrefslogtreecommitdiff
path: root/content/blog/2023
diff options
context:
space:
mode:
authormms <michal@sapka.me>2023-12-12 21:34:42 +0100
committermms <michal@sapka.me>2023-12-12 21:34:42 +0100
commit72b44f302d41df3caceed23cb925dc382b864996 (patch)
treea25867874cea69e5482ad00274693445980f417c /content/blog/2023
parent867d235681b1ad5201a63c04b8d9dbad365ae9c5 (diff)
tidy up: fixes and bsd extaction
Diffstat (limited to 'content/blog/2023')
-rw-r--r--content/blog/2023/tar-is-for-tape-drive.md8
1 files changed, 8 insertions, 0 deletions
diff --git a/content/blog/2023/tar-is-for-tape-drive.md b/content/blog/2023/tar-is-for-tape-drive.md
index e8c332c..ad6044b 100644
--- a/content/blog/2023/tar-is-for-tape-drive.md
+++ b/content/blog/2023/tar-is-for-tape-drive.md
@@ -29,3 +29,11 @@ This explains two things I never got about tar:
Tar is one of the things where computer archeology makes things clearer. Nowadays, we often forget that computers have a history and a lot of things we take for granted need to be invented. Many quirks can be understood if we explore the past a bit.
+**Errata**
+
+[Humm](https://bsd.network/@humm) pointed to me that the above is not technically true.
+
+1. Looking at low level, what makes tar slower than ZIP is lack of index. Zip files have an index which allows finding and reading the expected file. In tar, we need to seek and read file header to determine if this part of the archive contains the file we need. And this forces us to read all files before, so if it's our file let's extract it; otherwise look at the next header.
+2. It is fully possible to compress a file with a streaming archiver, like gzip and read the headers as we are streaming the archive.
+
+Thanks!