I suggest adding an option to change metadata such as volume ID without adding a new session (where possible).

When trying to modify a volume label using:

xorriso -dev tmp.iso -volid "new volume label"

xorriso indeed changes the volume label, but also adds a new session at the end. Of course, this is unavoidable on write-once media, but on overwritable media and disc images, it should be possible to modify the metadata of an existing session (such as volume label) without adding a new session.

My suggestion would be something like this:

xorriso -dev tmp.iso -edit_session 1 -volid "new volume label"

This will only change the volume label of the first session without adding a new session at the end, if it is possible. Otherwise (on write-once media), xorriso will return an error.

Also, some commands like -map (adding new files) would be impossible on an older session because unlike metadata fields (fixed size), the file and directory metadata have a variable length.

I also suggest an -append-only option like this:

xorriso -dev tmp.iso -append-only -volid "new volume label"

This would mimic writing on write-once media regardless of media type, by only appending data at the end without touching the first session.

Hi,

this is a very big wish for which no infrastructure is present in
xorriso. The idea of changing data in existing sessions is not yet
in the concept of xorriso (except maybe in -truncate_overwritable).
As you mentioned, many operations of xorriso would not be adaptable
to in-session editing.


I could imagine a simple tool which patches ISO 9660 superblocks
of which the session start is given as block address. This block
address would be 0 for the default-mountable superblock. The
superblocks of the particular sessions are listed by command -toc
under "sbsector". E.g.:

  TOC layout   : Idx ,  sbsector ,       Size , Volume Id
  ISO session  :   1 ,        32 ,   1340329s , HOME_Z_2026_01_24_222106
  ISO session  :   2 ,   1340384 ,     34330s , HOME_Z_2026_01_31_225237

The address of the Volume Id is

  (sbsector + 16) * 2048 + 40

The number of bytes at that adress is 32.
See ECMA-119 8.4 "Primary Volume Descriptor" for start bytes (plus one)
and end bytes (plus one). E.g. the specs say:

  41 to 72  Volume Identifier

So the byte offset in the PVD is 40 and the size is (72 - 41 + 1) = 32.


Have a nice day :)

Thomas