Hi, Will Mengarini wrote: > Note that the file-type character "h" (the leftmost character in your > second line of output) isn't documented in > <https://www.gnu.org/software/coreutils/manual/html_node/What-information-is-listed.html>,
The 'h' probably comes from https://sources.debian.org/src/tar/1.34%2Bdfsg-1/src/list.c/#L1188 which converts tar file type LNKTYPE to 'h'. This type is set when dump_hard_link() detects that there is already a file in the archive with the same device and inode number: https://sources.debian.org/src/tar/1.34+dfsg-1/src/create.c/?hl=1519#L1483 The only caller of dump_hard_link() is dump_file0(), where it happens unconditionally. (Thanks go to https://codesearch.debian.net ) > I'm not aware that ext$i filesystems can distinguish hard > links from original names. It's tar which does it by the (dev,ino) comparison in dump_hard_link(). I have a test case from xorriso development: $ ls -l test/hardlinks total 88 -rw-r--r-- 2 thomas thomas 42786 Nov 14 2008 hardlink_x -rw-r--r-- 2 thomas thomas 42786 Nov 14 2008 x Let's see what tar does with it: $ tar cf - test/hardlinks | tar tvf - drwxr-xr-x thomas/thomas 0 2009-05-18 19:57 test/hardlinks/ -rw-r--r-- thomas/thomas 42786 2008-11-14 09:44 test/hardlinks/x hrw-r--r-- thomas/thomas 0 2008-11-14 09:44 test/hardlinks/hardlink_x link to u/test/hardlinks/x I assume that it depends on the quite random order of file listing by readdir(3) which of both link siblings keeps type '-' and which becomes 'h' in the tarball. The question remains why jr's tar records two files with the same path as a pair of hardlinks. (I place my bet on btrfs snapshots.) Have a nice day :) Thomas
