Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support
Hi,
James Addison wrote:
> I've opened a merge request at
> https://salsa.debian.org/images-team/debian-cd/-/merge_requests/30
> [...]
> The commit message contains an effort to explain what's going on; please
> consider that message as reviewable and open to feedback too.
I'm clumsy with web based development. So my comments by mail:
----------------------------------------------------------------------
Commit message:
> When creating links to firmware files on the installation media in
> the /firmware directory, want to retain the same content de-duplication
> and resulting space-saving efficiencies as symlinks have provided.
Shouldn't that be ", we want to" ?
Since the symlinks are currently produced, shouldn't it be "as symlinks
currently provide." ?
(Disclaimer: I'm not a native speaker of english.)
> We'd also like the file entries that are created on the disc image
> to be compatible-with and copyable-from as many operating systems
> as possible.
It's rather about being copyable _to_ many filesystems by many operating
systems.
Actually it is mostly about FAT as target filesystem. It is the intended
target for copying because EFI is willing to search for its boot program
in about any partition with a FAT filesystem. (The specs prescribe special
partition types but in practice EFI does not care.)
Pete Batard's use case has two problems with symbolic links:
- The FAT filesystem has no concept of links.
- MS-Windows does not read Rock Ridge and thus ignores the symbolic link
info anyways. (But this problem is not significant in the end.)
So how about:
"We'd also like the files of the ISO 9660 filesystem to be copyable to
as many filesystems by as many operating systems as possible."
> Symlinks have some drawbacks in that regard, since not all operating
> systems fully support symbolic linking.
I propose to write:
"Links are not supported everywhere. The best substitute is to create
independent copies of the link target file for every link which is
encountered."
> Fortunately, the ISO9660 format supports a standardized way to refer
> to a common block of content (by referencing a starting block and a
> block count on-disc) from multiple file paths.
> Both genisofs and xorriso (CD image generation tools) support those kind
> of shared content file references, and are able to replace multiple
> hardlinks (POSIX links) that reference a single on-disk file with a
> single shared content range in the output disc image.
How about:
"The free ISO 9660 specs ECMA-119 give in 6.5.1 permission to use the
same file content blocks for multiple files. The ISO 9660 generation
tools genisoimage and xorriso do this to represent hard link relations
among their input files and to save space.
Reading operating systems usually perceive the files as not hardlinked,
though. So this representation of hard links causes creation of the
desired independent data files when they get copied out of the ISO
filesystem."
man genisoimage says that this feature is enabled by default on "Unix-like
operating systems" and can be disabled by option -no-cache-inodes .
xorriso does not offer to disable it. Its mkisofs emulation ignores the
option -no-cache-inodes .
> Those tools won't do that by default for symlinks, however (for cautious
> and sensible reasons related partly to the potential for
> infinite-link-loops), and so
The tools represent symbolic links in form of Rock Ridge SL entries.
The current Debian ISOs mounted by Linux show the links and Linux follows
them just fine. (Else it won't work for the Debian Installer.)
Handling of infinite link loops is the job of the reader.
So i propose to omit this part of the sentence.
> this changeset switches from the Perl symlink function (that
> creates symbolic links) to the more configurable debian-cd good_link
> function that will create links based on the demands of the
> environment it is configured in.
Well, this aspect is out of my area of expertise.
Have a nice day :)
Thomas
Reply to: