Hi, Christopher Baines <m...@cbaines.net> skribis:
> This test seems to fail, maybe because of high inode numbers, maybe > something to with btrfs. Uh. > scheme@(guix-user)> (file->cpio-header "guix/guix.scm") > $1 = #<<cpio-header> magic: 460545 ino: 5031515288 mode: 33188 uid: 1003 gid: > 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 > rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0> [...] > (let ((port (open-bytevector-input-port (get-bv)))) > (equal? (peek "A" header) > (peek "B" (read-cpio-header port)))))) > > ;;; ("A" #<<cpio-header> magic: 460545 ino: 5031515288 mode: 33188 uid: 1003 > gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 > rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>) > > ;;; ("B" #<<cpio-header> magic: 460545 ino: 736547992 mode: 33188 uid: 1003 > gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 > rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>) > $3 = #f (guix cpio) defines cpio headers like this: --8<---------------cut here---------------start------------->8--- (define-pack <cpio-header> %make-cpio-header cpio-header? write-cpio-header read-cpio-header (magic 6 cpio-header-magic) (ino 8 cpio-header-inode) (mode 8 cpio-header-mode) (uid 8 cpio-header-uid) (gid 8 cpio-header-gid) (nlink 8 cpio-header-nlink) (mtime 8 cpio-header-mtime) (file-size 8 cpio-header-file-size) (dev-maj 8 cpio-header-device-major) (dev-min 8 cpio-header-device-minor) (rdev-maj 8 cpio-header-rdevice-major) (rdev-min 8 cpio-header-rdevice-minor) (name-size 8 cpio-header-name-size) (checksum 8 cpio-header-checksum)) ;0 for "newc" format --8<---------------cut here---------------end--------------->8--- The ‘ino’ value is stored as an 8-digit hexadecimal number—i.e., on 32 bits. And, guess what: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> 5031515288 ;the inode number above $15 = 5031515288 scheme@(guile-user)> (expt 2 32) $16 = 4294967296 scheme@(guile-user)> (- $16 $15) $17 = -736547992 --8<---------------cut here---------------end--------------->8--- Noways, libc + kernel typically use a 64-bit ‘ino_t’, so fundamentally the cpio format is “wrong”. But what can we do? At least we can skip this test when that is the case (patch below). WDYT? Thanks, Ludo’.
diff --git a/tests/cpio.scm b/tests/cpio.scm index 516de0655b..832101d1bb 100644 --- a/tests/cpio.scm +++ b/tests/cpio.scm @@ -1,5 +1,5 @@ ;;; GNU Guix --- Functional package management for GNU -;;; Copyright © 2015 Ludovic Courtès <l...@gnu.org> +;;; Copyright © 2015, 2022 Ludovic Courtès <l...@gnu.org> ;;; ;;; This file is part of GNU Guix. ;;; @@ -31,12 +31,18 @@ (define-module (test-cpio) (define %cpio-program (which "cpio")) +(define %test-file + (search-path %load-path "guix.scm")) + (test-begin "cpio") +;; The cpio format expects 'ino' to fit in 32 bits. If we have a bigger inode +;; number, skip this test. +(test-skip + (if (>= (stat:ino (lstat %test-file)) (expt 2 32)) 1 0)) (test-assert "file->cpio-header + write-cpio-header + read-cpio-header" - (let* ((file (search-path %load-path "guix.scm")) - (header (file->cpio-header file))) + (let* ((header (file->cpio-header %test-file))) (call-with-values (lambda () (open-bytevector-output-port))