[Log in to get rid of this advertisement]

While growisofs and genisoimage can create UDF file systems, they require the existence of an ISO9660 file system to resume a disc, meaning to create more than one session. It can not resume UDF-only file systems that have no co-existing ISO9660 tree. It also can not resume file systems that have files above 2 GB, which is a limitation of ISO9660. And xorriso can only work with ISO9660. mkudffs can, as the name implies, only create new UDF file systems.

Is there any multisessioning tool that can work with UDF-only discs?

I am not talking about packet writing (which is also poorly supported on Linux), but sequential multisession writing.

On Windows, there are plenty of tools for this since the 2000s: ImgBurn, Nero, CDBurnerXP. Please don't tell me nothing has been developed for this for Linux in over two decades.

(For reference, ISO9660 was made for CD-ROM, where as UDF for DVD and Blu-ray and any future media, since its file size limitation is in the exabyte realm.)

Before anyone asks "Why don't you just use Rock Ridge?":

Rock Ridge is not a file system of its own. It is an extension for ISO9660. What it does is enable longer file names and Unix-style permissions (rwxrwxrwx), but it does not get past the 2 GB limit of ISO9660 (which was designed for 700MB CD-ROMs to begin with).

Joliet is also an extension for ISO9660, not a file system. Its official specification has a 64-character limit. However, it technically supports up to 103 characters according to Wikipedia, but some devices might not recognize file names beyond 64 characters (e.g. a DVD player I tested it with). Still, this is well below the 255 characters supported by Rock Ridge and UDF.

This means ISO9660 is useless for storing files beyond 2 GB. According to Wikipedia, the limit is 4.2 GB and duplicate entries of the same file can get past that limit, but growisofs and genisoimage appear to not have implemented this.

genisoimage and growisofs can create a hybrid file system where ISO9660 and UDF reference the same files. But they can only create multisession from ISO9660 file systems. It can not expand an existing UDF file system and can not convert UDF into a hybrid (ISO9660+UDF) file system.

In other words, you can not have both files over 2 GB and multisession. If you want to create a disc with files over 2 GB, you need to fill the entire disc in one go, or you waste any unused space.

https://www.man7.org/linux/man-pages...udfinfo.1.html
Search for Multisession.

I've never tried to make a multisession UDF disk.

Hi,

exerceo wrote:
> Rock Ridge [...] does not get past the 2 GB limit of ISO9660

There is no such limit in the ISO 9660 / ECMA-119 specification.
(2 GiB was an old Linux limit when file size was stored in signed
32 bit integers.)

The limit of "Level of interchange" 1 and 2 is 4 GiB - 1.
The limit for level 3 is the maximum size of an ISO 9660 filesystem,
i.e. nearly 8 TiB. This is achieved by having multiple directory records
for the same file name (aka multi-extent).

(Released xorriso has a filesystem limit of 4 TiB because of libburn
and own use of 32 bit signed integers. This will be raised to the
theoretical maximum of 8 TiB in the next release.)

Mounting and reading level 3 is supported at least by Linux and by
MS-Windows. If the operating system does not support multiple extents
then xorriso can still copy multi-extent files out of the ISO filesystem.

xorriso in its native command mode enables level 3 by default.
For its mkisofs emulation it uses the traditional default 1, which can
be overriden by option [code] -iso--level 3[code].


> According to https://en.wikipedia.org/wiki/ISO_9660#Directories_and_files
> the limit is 4.2 GB

No. It mentions 4.2 GB as limit for a single extent:

"* Level 3: [...] Files are also allowed to consist of multiple
non-contiguous sections (with some restrictions as to order).
[...]
As the length of a file's extent on disc is stored in a 32 bit value,
it allows for a maximum length of just over 4.2 GB (more precisely, one
byte less than 4 GiB). It is possible to circumvent this limitation
by using the multi-extent (fragmentation) feature of ISO 9660 Level 3
to create ISO 9660 file systems and single files up to 8 TB. With this,
files larger than 4 GiB can be split up into multiple extents
(sequential series of sectors), each not exceeding the 4 GiB limit.
For example, the free software such as [...] mkisofs [...] are able
to create ISO 9660 file systems that use multi-extent files to store
files larger than 4 GiB on appropriate media such as recordable DVDs.
[...] Linux supports multiple extents."


> In other words, you can not have both files over 2 GB and multisession.

You are invited to try:

You will see /mnt/iso/file1 and /mnt/iso/file2 with their large sizes
(as long as they are below 4 TiB, that is). Use "wc" to count their
bytes if you do not believe the sizes given by "ls -l".

Have a nice day

Thomas

2 members found this post helpful.

Thank you Thomas - nice to get real information rather than uninformed conjecture perpetrated yet again.

Hi,

syg00 wrote:
> nice to get real information rather than uninformed conjecture
> perpetrated yet again.

There are reasons why people can get to these wrong assessments:

The web is full of misinformation, including references to the totally
outdated Linux file size limit of 2 GiB - 1.

exerceo, the original poster of this thread, possibly tried with growisofs
and genisoimage, which seems to indeed ignore option "-iso-level 3". See
https://www.linuxquestions.org/quest...ile-4g-581814/

I just verified that it indeed refuses on a file of 8 GiB
But as above old thread from 2007 mentions, mkisofs usually obeys this
option.

xorriso's mkisofs emulation obeys, too:
People who prefer to use growisofs for multi-session burning, instead
of native xorriso as shown in my previous post, may use xorrisofs
instead of genisoimage or mkisofs by:
Original growisofs looks at variable MKISOFS, Debian's at GENISOMAGE.
See
https://sources.debian.org/src/dvd%2...ode.patch/#L28

The Debian developer who forked genisoimage and wodim in 2006 meanwhile
deprecated both for most puposes. Only genisoimage runs with option "-udf"
or "-hfs", and exotic wodim CD write options like "-xa" or "-raw96r" are
still valid reasons to use these programs. Your mileage may vary.

Debian still makes its inofficial ISOs for the "powerpc" architecture
by genisoimage because they need option "-hfs". All official ISOs, e.g.
for "amd64", "i386", "arm64", are made by xorrisofs.

Have a nice day

Thomas

1 members found this post helpful.

udfinfo is, as the name implies, for showing information about a UDF file system. It does not write any data.

My goal is to write multisession data.

(I will respond to the other posts shortly, I just wanted to get this one out of the way.)

Then how come the growisofs manual states this?

Is this an error?


I see.

But it appears genisoimage and growisofs don't make use of this ability.

Unfortunately, xorriso does not support UDF.

Nonetheless, thanks for your response, Thomas. These are interesting insights.

Hi,

Plainly: Yes.

The Debian developers who forked genisoimage from mkisofs not only
spoiled "-iso-level 3" but also invented reasoning for this in ~2007.
About the fork, see https://en.wikipedia.org/wiki/Cdrkit

Don't get me wrong: Those guys are my friends. One of them, former
Debian Project Leader Steve McIntyre, still leads production of Debian
installation ISOs by help of xorriso, of which i am the developer (if
that did not become obvious until now).

In my second post i show how you can uses xorrisofs instead of genisoimage
by giving growisofs the name "xorrisofs" in the exported variable MKISOFS
and GENISOIMAGE. Set both of them, to cater for both growisofs flavors.

You motivated your wish for UDF by the need to store large files on
optical media. Well, that wish can be fulfilled by ISO 9660, too.

I am indeed not aware of a program for UDF multi-session on GNU/Linux.

The specifications ECMA-167 and UDF-2.60 are ugly to read.
Obviously nobody in the free software community was motivated enough
to implement the multi-session aspect on optical media.
For multi-session on ISO 9660 (aka ECMA-119) there were a handful of
interested programmers. I am the last who is still active on that topic.

And i do my daily incremental backups on BD-R, BD-RE, and DVD+RW media.
Record holder is a BD-RE with
More than two years of daily snapshots of about 5 GB of various software
projects and personal data. Many of the files are zisofs compressed, a
format known to the iso9660 driver of the Linux kernel. Regrettably zisofs
is restricted to files which are smaller than 4 GiB.

If you want more than 128 sessions on BD-R, you need an ASUS BW-16D1HT
burner. LG for example closes BD-R automatically after 128 to 135
sessions.
To our luck the multi-session on BD-RE is emulated similar to
what growisofs does. So there is few wasted space between sessions and
no limit on the number of sessions. The risk of medium failure lets me do
these backups twice on separate media. If one BD-RE fails, i copy the
other to a new one before i go on with more sessions.

Have a nice day

Thomas

1 members found this post helpful.

I see. Thanks for explaining. I have a suggestion for xorriso: It should not spin down the disc after finishing a command, for example:

Spinning down actually increases power consumption because the drive needs to spin up again if the user accesses any data. And having to spin up again adds delays when running multiple commands.

If spinning down the disc is desirable, it can already be accomplished using one of these:

hdparm appears to only work with internal drives, not external drives or externally connected internal drives.

It appears more recent HL-DT-ST slim drives do not forcibly spin down the disc when entering stand-by mode, but just let it spin down on its own (like hard drives do). This saves power compared to forcibly slowing down the disc, because that takes effort. But most optical drives ever made waste energy on forcibly slowing down the disc. This also has the disadvantage that if the user tries to access data in the exact second a drive spins down the disc, they need to wait for the disc to spin down to zero speed and then spin up again, which can take over five seconds.

UDF support is necessary to make file names with over 64 characters readable on Windoze because the Joliet extension for ISO9660 has a 64-character limit, and the Rock Ridge extension for ISO9660 is unsupported on Windoze.

I am not even sure if Windoze is able to recognize multi-part ISO9660 files that exceed 4 GB.

I think lots of code from genisoimage and growisofs can be re-used. After all, all that needs to be done is to take an existing UDF file tree and add some new entries with new sector numbers to it in each directory where new files were added. The existing files with the existing sector numbers can simply be imported from the previous session (or an earlier session if the user wishes so).

If this is already possible for ISO9660, and genisoimage can already create single-session UDF, multisession UDF shouldn't be too distant.

genisoimage and growisofs can not create UDF-only images, they can only add UDF to ISO9660. Only mkudffs can create UDF-only images, but it can not add any files to them. Curiously, mkudffs is able to create empty UDF 1.01, 1.02, and 1.50 images, but Linux can't write any data to them.

It doesn't have to be UDF 2.60. UDF 1.02 (the classic version which is used on DVD) is enough for multisessioning.

UDF 1.50 and above is for more fancy stuff like packet writing (using an ordinary file manager) and DVD recording, and UDF 2.60 is for Pseudo Overwrite on BD-R, but this being implemented on Linux is a distant dream for now. It was requested in 2008; perhaps it will finally have been done by 2040 (31 years after Windows 7 got it).

But UDF 2.60 writing is not urgent anyway, and UDF 2.60 reading is already thankfully supported, so packet-written discs created on Windows can at least be read on Linux.

UDF 1.02 multisessioning already fulfills the purpose of being able to add data to a disc incrementally.

776 sessions on a single disc?

And I am guessing Windoze won't recognize it either.

Good to know, Thomas. Thank you.

But the benefit of write-once media such as BD-R is that you can rest assured that nothing can tamper with the data once it's written, so it is inviolable by malware or unlikely accidental overwriting.

A failed burn of write-once media should ideally be handled by creating a new cleaned-up file tree in a new session, with all non-written files removed. Obviously, the the one "break point" file that was partially written should also be removed from the file tree. After that, the missing files can be added again in a new session with a new file tree.

genisoimage, and consequently growisofs and K3b which rely on it, are unfortunately unable to remove existing files from an imported session. This has been requested in 2004 but is still not implemented in K3b, whereas Windows tools like ImgBurn and CDburnerXP had this since the 2000s.

Looking at the manual of xorriso, it has an -rm option for this purpose. I haven't tried it yet, but I am assuming it will work, so thank you for implementing it.

Hi,

Within the same xorriso run, this can be disabled by command -calm_drive.
The command may be written into a startup file, like $HOME/.xorrisorc .

At the end of the program run, the calming is done unconditionally.
I will think about a new mode for -calm_drive which prevents this.
(Main obstacle for a quick hack is that libisoburn and libburn do not
offer an opportunity for this in their API calls *_drive_release()
although the non-API libburn call burn_drive_release_fl() offers this.)

Somebody with a MS-Windows machine should make experiments and report
the outcome. Very old Linux and some of the BSDs have problems with
directory trees which are stored above 4 GiB.

The idea of the overall superblock and session superblocks was invented
by Andy Polyakov for growisofs. The idea of a recognizable chain of
session blocks is by me. For details see
"ISO 9660 multi-session emulation on overwriteable media" and
"ISO 9660 based TOC emulation on overwriteable media" in
https://dev.lovelyhq.com/libburnia/l...c/cookbook.txt

growisofs has no own stake in ISO 9660 or UDF. It just operates the drive
and leaves filesystem production to an external program.
The UDF capability of genisoimage is inherited from mkisofs. Out of
copyright reasons i never took code or widescale code concepts from
mkisofs. (Joerg Schilling was opposed to my work. I respect this even
posthumously.)

I do not expect that the hardware TOC of BD-R media would take such an
amount. But with the emulated TOC on BD-RE the only hard limit is media
size. A soft limit is the time to assess all sessions.
Meanwhile my backup needs nearly half a minute:
(The "50 MB" are computed from 795 read operations of 64 KiB which load
the system area and the volume descriptors of each session while crawling
along the session chain.)

I will probably have to employ new BD-RE media in about a month.

The drawback is that the multi-session structure cannot be easily copied
to another medium. One would have to load session by session from the
origin medium and create them one-by-one on the target medium.
Also there are firmware limits and probably medium limits for the number
of sessions.

A damaged TOC on BD-R normally makes the whole medium unreadable
whereas on BD-RE there is much more hope to retrieve much of the data.

Regrettably the development of GUI burner programs had already ended
when xorriso gained a standing in the GNU/Linux world. So the only GUI
program on GNU/Linux which offers removal/hiding of files is my demo
xorriso-tcltk. See https://packages.debian.org/bookworm/xorriso-tcltk

I test this capability daily by my backup runs which use xorriso command
-update_r. New or changed files get added to the new session. Vanished
files get removed/hidden from the new session but stay accessible from
the previous session.

Have a nice day

Thomas