[mzs]

"symlink is just a file…"

A file for which you exclusively use lstat() & readlink() instead of all the other usual functions in the standard library you use for regular files. What about named pipes? Or sockets? Or whiteout? Are they too just files since they have a filename?

[bigiain]

"Please wait: backing up /dev/urandom - 0% of NaN"

(To be fair, anyone who tries to backup /dev deserves whatever they get...)

[mzs]

  $ echo /dev/urandom | cpio -o | xxd -a
  1 block
  00000000: 3037 3037 3037 3737 3737 3737 3030 3030  0707077777770000
  00000010: 3031 3032 3036 3636 3030 3030 3030 3030  0102066600000000
  00000020: 3030 3030 3030 3030 3031 3737 3737 3737  0000000001777777
  00000030: 3133 3436 3430 3530 3035 3730 3030 3031  1346405005700001
  00000040: 3530 3030 3030 3030 3030 3030 2f64 6576  500000000000/dev
  00000050: 2f75 7261 6e64 6f6d 0030 3730 3730 3730  /urandom.0707070
  00000060: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
  00000070: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
  00000080: 3030 3130 3030 3030 3030 3030 3030 3030  0010000000000000
  00000090: 3030 3030 3030 3030 3133 3030 3030 3030  0000000013000000
  000000a0: 3030 3030 3054 5241 494c 4552 2121 2100  00000TRAILER!!!.
  000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  *
  000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  $ echo $?
  0

[jolmg]

I chuckled at the "TRAILER!!!". I wonder what other file formats have silly things like this.

From `man 5 cpio`:

> The end of the archive is indicated by a special record with the pathname “TRAILER!!!”.

This makes me wonder if this means that the cpio format can't reliably be used for files with the path "TRAILER!!!". Why would the format even need a special record to indicate the end of the archive? Is there any reason why one wouldn't be able to rely on the end of the file to indicate the end of the archive?

[jolmg]

Seems cpio really can't deal with "TRAILER!!!" files:

  $ cd $(mktemp -d)
  $ echo foo > 'TRAILER!!!'     
  $ echo bar > barfile
  $ echo 'TRAILER!!!' | cpio -o | xxd -a
  1 block
  00000000: c771 2a00 31cc a481 e803 e803 0100 0000  .q*.1...........
  00000010: 025d ef8c 0b00 0000 0400 5452 4149 4c45  .]........TRAILE
  00000020: 5221 2121 0000 666f 6f0a c771 0000 0000  R!!!..foo..q....
  00000030: 0000 0000 0000 0100 0000 0000 0000 0b00  ................
  00000040: 0000 0000 5452 4149 4c45 5221 2121 0000  ....TRAILER!!!..
  00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  *
  000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  $ echo 'TRAILER!!!' | cpio -o | cpio -t
  1 block
  1 block
  $ echo barfile | cpio -o | cpio -t
  1 block
  barfile
  1 block
  $ echo barfile | cpio -o | cpio -i --to-stdout barfile 
  1 block
  bar
  1 block
  $ echo 'TRAILER!!!' | cpio -o | cpio -i --to-stdout 'TRAILER!!!'
  1 block
  1 block

[mzs]

tar has two blocks of zeros at the end.

GNU tar uses entries where other tar implementations will overwrite previous files on extraction, AIX tar uses special four character names for binary blobs (plus xattrs as names, both after the affected entry), Solaris cpio uses another mode bit for sparse files, ACLs, and xattrs (I actually really like this, it extracts as a simple to parse text file[0] on other implementations), and most pax commands on Linux can't read/write PAX archive files.

FWIW I make use of TRAILER!!! to let me know in a pipeline that everything worked (imagine a command earlier in the pipe fails early and not every entry is processed but ends on a boundary), but here the two pages of zeros that tar uses makes more sense (about the only thing tar does better than cpio).

0: https://www.mail-archive.com/[e-mail]...

[ktpsns]

How does this work? Looks like a bug in xxd for me (o.O)

[mzs]

Nope xxd is fine, read the man page.

  $ PAGER='col -bx' man 5 cpio | awk '$1 == "mode" { print; while (getline) print }' | head
  mode    The mode specifies both the regular permissions and the file
          type.  It consists of several bit fields as follows:
          0170000  This masks the file type bits.
          0140000  File type value for sockets.
          0120000  File type value for symbolic links.  For symbolic links,
                   the link body is stored as file data.
          0100000  File type value for regular files.
          0060000  File type value for block special devices.
          0040000  File type value for directories.
          0020000  File type value for character special devices.
  $ echo /dev/urandom | cpio -o | dd bs=6 skip=3 count=1 | od -tc
  1 block
  1+0 records in
  1+0 records out
  6 bytes transferred in 0.000025 secs (239675 bytes/sec)
  0000000    0   2   0   6   6   6                                        
  0000006