Hi,
Gerd Hoffmann wrote:
> There isn't something like a link
> count field in the directory listing, so this is *not* visible with
> "ls".
There is something like a link count field. But a link count > 1 makes
full sense only if the link siblings have the same inode number. Those
numbers can be recorded in Rock Ridge entry PX if Rock Ridge 1.12 is
enabled:
xorriso -compliance new_rr -as mkisofs ...usual.options...
But the production of Fedora ISOs does not generate them this way and the
interpretation in the Linux kernel would ignore them.
> The only way to figure the link count is scanning the whole file
> system
Not with Linux.
# mount Fedora-Workstation-Live-x86_64-31-1.9.iso
$ ls -l /mnt/iso/images/pxeboot
total 65293
-rw-r--r-- 2 root root 57536044 Oct 24 2019 initrd.img
-rwxr-xr-x 2 root root 9323208 Oct 21 2019 vmlinuz
The PX entry has a field "POSIX File Links" which "shall be used for the
st_nlink field of POSIX:5.6.1.".
This is present even in RRIP 1.10 but makes few sense there, because no
inode numbers can be recorded in 1.10.
Nevertheless Linux interprets this value in fs/isofs/rock.c :
case SIG('P', 'X'):
inode->i_mode = isonum_733(rr->u.PX.mode);
set_nlink(inode, isonum_733(rr->u.PX.n_links));
Simple example:
echo hello >/tmp/x
xorriso -as mkisofs -o test.iso -graft-points /x=/tmp/x /y=/tmp/x
mount test.iso /mnt/iso
ls -li /mnt/iso
yields
total 1
1159 -rw-r--r-- 2 thomas thomas 6 Oct 26 09:58 x
1162 -rw-r--r-- 2 thomas thomas 6 Oct 26 09:58 y
But, as said, Linux does not care if a PX entry has length >= 44 and thus
a field "File Serial Number". The struct RR_PX_s in fs/isofs/rock.h has
no field member for byte offset 36 to 43.
So we have no consistent display of effectively hardlinked files.
The shown inode numbers roughly tell where the directory entries of the
files are:
$ expr 1159 '*' 32
37088
$ dd if=test.iso bs=1 skip=37088 count=110 | od -c
0000000 \b : ( \0 j \0 ! \0 \0 \0 \0 \0 \0 ! 006 \0
0000020 \0 \0 \0 \0 \0 006 x \n 032 \b : 026 \0 \0 \0 \0
0000040 001 \0 \0 001 004 X . ; 1 \0 P X $ 001 244 201
0000060 \0 \0 \0 \0 201 244 002 \0 \0 \0 \0 \0 \0 002 350 003
0000100 \0 \0 \0 \0 003 350 350 003 \0 \0 \0 \0 003 350 T F
0000120 032 001 016 x \n 032 \b : 026 \0 x \a 020 \v 030 /
0000140 \0 x \n 032 \b : 026 \0 N M 006 001 \0 x
0000156
The ISO 9660 name start byte "X" marks byte offset 33 in the directory
record. So the "j" = 106 decimal is the size of the record. The record
ends by the Rock Ridge name entry NM, telling the Rock Ridge file name "x".
PX has size 36 and thus contains no File Serial number.
With RRIP 1.12 it looks like:
$ dd if=test.iso bs=1 skip=37088 count=144 | od -c
0000000 032 001 016 x \n 032 \t 020 * \0 x \n 032 \t 020 *
0000020 \0 x \n 032 \t 020 * \0 N M 005 001 004 \0 r \0
0000040 ! \0 \0 \0 \0 \0 \0 ! 006 \0 \0 \0 \0 \0 \0 006
0000060 x \n 032 \b : 026 \0 \0 \0 \0 001 \0 \0 001 004 X
0000100 . ; 1 \0 P X , 001 244 201 \0 \0 \0 \0 201 244
0000120 002 \0 \0 \0 \0 \0 \0 002 350 003 \0 \0 \0 \0 003 350
0000140 350 003 \0 \0 \0 \0 003 350 002 \0 \0 \0 \0 \0 \0 002
0000160 T F 032 001 016 x \n 032 \b : 026 \0 x \n 032 \b
0000200 : ( \0 x \n 032 \b : 026 \0 N M 006 001 \0 x
The directory record starts at the first "r", i.e. length is 114.
Here we see PX of size 44 (",") with last field value
002 \0 \0 \0 \0 \0 \0 002
which is how ISO 9660 expresses the 32 bit value 2 (before "T F").
In the next directory record we see the same File Serial Number 2 (again
before the field name "T F"):
$ dd if=test.iso bs=1 skip=37232 count=114 | od -c
0000000 r \0 ! \0 \0 \0 \0 \0 \0 ! 006 \0 \0 \0 \0 \0
0000020 \0 006 x \n 032 \b : 026 \0 \0 \0 \0 001 \0 \0 001
0000040 004 Y . ; 1 \0 P X , 001 244 201 \0 \0 \0 \0
0000060 201 244 002 \0 \0 \0 \0 \0 \0 002 350 003 \0 \0 \0 \0
0000100 003 350 350 003 \0 \0 \0 \0 003 350 002 \0 \0 \0 \0 \0
0000120 \0 002 T F 032 001 016 x \n 032 \b : 026 \0 x \n
0000140 032 \b : ( \0 x \n 032 \b : 026 \0 N M 006 001
0000160 \0 y
0000162
I am not aware how complicated it would be to put that number 2 into
struct inode.i_ino without confusing the overall isofs driver.
The act itself would be quite trivial in above code snippet after having
extended struct RR_PX_s by the RRIP 1.12 field and interpreting the
member .len of struct rock_ridge to evaluate whether the new field is
valid.
Without reading the inode number of a file from the ISO it makes few sense
to read its link count instead of setting it flatly to 1. So an easy
change towards consistency would be to ignore rr->u.PX.n_links.
(If anybody here has a standing in kernel modules cdrom, scsi, or isofs:
I have bug fixes and helpful enhancements, but linux-scsi ignores my
first patch submission attempt since > 6 weeks.)
Have a nice day :)
Thomas
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
