[Toybox] [cpio] Various questions (mtime, inode number)

[Yi-yo Chiang]

Was playing with the new cpio command and spotted a few oddities. Some of
which I'm not sure are bugs or WAI?

1. cpio -i might not preserve mtime, due to later entries might modify
previous entries' mtime.

$ mkdir a && touch a/b
$ touch -d @0 a a/b
$ ls -al a
total 8
drwxr-xr-x 2 yochiang primarygroup 4096 Jan  1  1970 .
drwxr-xr-x 4 yochiang primarygroup 4096 Apr 22 20:35 ..
-rw-r--r-- 1 yochiang primarygroup    0 Jan  1  1970 b

$ # both a/ and a/b have timestamp at epoch+0
$ find a | toybox cpio -H newc -o >a.cpio
$ mkdir stage && cd stage
$ toybox cpio -i <../a.cpio
$ ls -al a
total 8
drwxr-xr-x 2 yochiang primarygroup 4096 Apr 22 20:37 .
drwxr-xr-x 3 yochiang primarygroup 4096 Apr 22 20:37 ..
-rw-r--r-- 1 yochiang primarygroup    0 Jan  1  1970 b

The timestamp of a/b is correct, but a/ isn't. This is because a/ 's
timestamp was updated when we create a/b.

Not sure if this is a design choice to simplify code?
Fixing this could mean we need a "fix-up" phase after all entries are
extracted and fix up all the extracted file's st_mtime, which means we
would memorize the list of all files we extract, which doesn't sound like a
good idea in terms of memory consumption?

2. Archives created by cpio command are non-deterministic due to unstable
inode numbers.

$ # using the same a.cpio from previous example
$ toybox cpio -idu <../a.cpio
$ find a | toybox cpio -H newc -o | sha1sum
d17aa2355dc17239b90cae724d74d6a56bef67c3  -
$ rm -rf ./*
$ toybox cpio -idu <../a.cpio
$ find a | toybox cpio -H newc -o | sha1sum
bf1428382bdb9240fedb38c46746a30d25ae4daa  -

Even though the source files are exactly the same, the produced
archives have different contents. Upon close inspection the diff happens in
the st_ino and st_mtime field.

How about we add an option, say "-s" for "stable" or "-P" for
"Portability", that changes the output to have deterministic output by
renumbering st_ino, st_mtime, st_dev and such?


-- 

Yi-yo Chiang
Software Engineer
yochiang at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210422/1b3ad797/attachment.htm>