Repository navigation
Multisession
Multisession is not supported and is not planned for the foreseeable future. This applies to raw and DAR mode, with either prepared disc folders or ISO output. bd-archiver cannot add files to an already burned disc, even if space remains.
Collect files on a hard drive before creating and burning the complete batch in
one session. To archive later additions, prepare a new disc. DAR incrementals
record changes in a new generation; they do not append to an already burned disc.
DAR --pack-with combines an unburned leftover folder or image with a new
archive before burning a new single-session disc.
burn --start N resumes a set at a prepared disc number. It neither continues an
interrupted write nor adds a session to a recorded disc. Skipping capacity checks
does not enable append support.
See Burning, Raw data discs, and Incrementals and packing for supported workflows.
The September 2026 investigation found no sufficiently simple, demonstrated open-source Linux solution meeting the project's requirements. This does not mean that UDF or BD-R inherently prevents later additions. The gap is a suitable UDF authoring implementation combined with reliable media handling and recovery.
A proprietary Linux SDK provides a concrete alternative, but its licensing does not fit this open-source tool. Moving burning to Windows is not being pursued. Extending a UDF author would also require substantial changes to capacity planning, disc identification, checksums/recovery metadata, burning and verification.
The current ISO9660+UDF format remains in use. There is no scheduled implementation or selected replacement backend. The findings below preserve the investigation for future reference; they are not instructions for an available append feature.
Research date: 2026-09-14. Application code reviewed at
6c8a368.
External versions, source findings and license terms below are observations from
that investigation and may change. No multisession image-generation or physical
burn experiments were performed. Documentation and source inspection establish
candidate capabilities, not reliable operation on a particular drive or player.
The requested behavior was to burn part of a BD-R and later add files, initially in raw mode, with all old and new files visible together through UDF on Linux. Modern operating systems and Panasonic DP-UB820 playback were also considered. An ISO9660 bridge was acceptable if its metadata cost was modest, but it could not replace updating UDF. Intentionally leaving UDF on the first session while only ISO9660 shows additions would not meet the requirement.
Player-specific session-selection limits were distinguished from a stale UDF filesystem. Complete recovery of every addition was required; specialized reading and mounting procedures were acceptable instead of one default ddrescue command.
Source paths below are relative to
src/bd_archive/ at the reviewed revision.
| Area | Current behavior | Consequence |
|---|---|---|
tools/mkisofs.py:22–35 |
Always -iso-level 3 -udf; raw additionally requests -R
|
Both modes create hybrid filesystems; Rock Ridge is an ISO9660 extension, not a third payload copy. |
tools/mkisofs.py:71–80 |
Documents shared payload blocks | Removing ISO9660 saves its metadata, not a duplicate set of files. |
tools/growisofs.py:88–95 |
Always writes through -Z
|
No application-level append workflow exists. |
tools/mediainfo.py |
First matching Free Blocks, then Track Size fallback | Not a trustworthy multi-track append-state model. |
commands/create_raw.py |
Automatic PAR2 sizing uses the available capacity | A small first batch may consume the remainder as recovery data unless given a smaller session budget. |
archive/disc_folder.py |
Measurement and manifest depend on mkisofs and rock_ridge
|
The UDF backend needs an explicit format/measurement contract. |
archive/verify.py:33–55 |
Raw verification selects one root recovery index | Additional payload could escape verification if this layout were merely extended. |
archive/disc.py, commands/verify.py
|
General device/loop mounting | A successful mount alone does not prove the intended latest session was selected. |
An earlier append design was rejected because it could expose a stale UDF view while ISO9660 contained later additions. Verification could then validate only the old archive and falsely appear to cover the whole disc. Other review findings included reversed session offsets, incorrect handling of compound track states, capacity arithmetic that failed with multiple previous sessions, and regressions for rewritable media.
The decisive practical detail was that the partly filled last disc had not been
burned. Combining its prepared contents with the next archive on one new disc
solved that need without adding on-media append support. That became --pack-with.
Those review findings did not identify ddrescue as the decisive reason for the decision. Reports of only the first session appearing in a copied image are consistent with session-discovery or read-range issues; see the recovery section.
The earlier blanket claim that no Linux software can create any UDF multisession structures was too broad: mkudffs documents session-offset support, and a Linux commercial SDK provides an append example. Neither establishes a suitable open-source replacement for the current application.
The presence of -dvd-compat does not by itself mean a BD-R is finalized. The
medium's actual state determines physical appendability, separately from whether
bd-archiver supports importing and extending its filesystem.
UDF 2.60 section 6.11.3 describes a latest session whose structures can reference data and metadata in earlier sessions. Sections 6.11.2 and 6.11.3 distinguish VAT incremental recording from session handling. Thus UDF is not inherently limited to one burn. For BD-R without logical overwrite, UDF 2.50 is a candidate target; choosing 2.60 merely because its number is newer is unjustified. The multisession ban in section 6.16.4.1 concerns BDAV/BDMV application usage, not every MKV data disc. UDF specification
| Component | Evidence | Assessment |
|---|---|---|
| mkisofs | Its manual explicitly says it always creates ISO9660. | Cannot author the requested pure-UDF format. Manual |
| growisofs 7.1 | The dev_found == 'M' path checks for CD001 before accepting even an image input. |
Its normal append path cannot be the pure-UDF transport. Source |
| cdrskin/libburn | Burns preformatted data and supports BD-R multisession. | Possible transport component; it does not create the UDF directory tree. Upstream |
| xorriso/libisofs | Provides ISO9660 authoring, import and multisession facilities, but no UDF author. | Does not fill the cumulative-UDF authoring gap; replacing growisofs with xorriso alone would not meet the requirement. Upstream |
| mkudffs 2.3 | Has --startblock, BD-R and VAT support; revisions above 2.01 are marked experimental. It creates a filesystem rather than importing a source tree plus previous extents. |
Useful formatter/reference, not a demonstrated complete authoring backend. Manual |
| Linux UDF driver | Explicitly refuses writable mounts of virtual partitions. | Mounting VAT-based BD-R read/write and copying files into it is not a solution. Source |
| UDFclient/newfs_udf | Source 0.8.21 explicitly returns an error for compiling/writing VAT; virtual-sector allocation is also unimplemented. | Not a complete VAT-based BD-R append writer. This finding is about the userland code, not NetBSD's kernel driver. Source archive |
The inspected wrudf code has a CD-R-oriented VAT writer emitting revision 1.50;
that is not proof of a suitable modern BD-R pipeline.
Source
The targeted UDFclient source inspection found udf.c:4629 reporting VAT write-out as
not implemented and udf_bmap.c rejecting virtual allocation. This was a focused
append-path inspection, not a complete audit. No physical-media or generated-image
experiments were performed in this investigation.
PrimoBurner, native Linux: the vendor's public C++ samples/linux/bluray-data
README explicitly demonstrates a first burn followed by an append. BurnerApp.cpp
sets ImageTypeFlags::Udf; Burner.cpp sets the new session address, finds the
previous complete track, requests its import through setLayoutLoadTrack, adds
the new source tree, and writes the disc. main.cpp leaves the disc open. This is
stronger evidence than independently advertised UDF and multisession features.
Linux example and instructions
Import/write path
Pure UDF selection
The sample selects UDF 1.02, so it is not itself a demonstrated UDF 2.50 append test. The SDK advertises revisions through 2.60 and exposes revision selection; 2.50 remains a proposed test target. The SDK supplies Linux shared libraries for Ubuntu 22.04 and later on amd64/aarch64. Its internals are proprietary; inspecting the MIT-licensed sample does not amount to auditing the filesystem implementation. Features
Standard commercial licensing is USD 6,000 per year, per product and platform. There is a conditional free license for qualifying noncommercial open-source projects, with annual renewal and restrictions including non-copyleft licensing and project activity requirements. Eligibility and distribution terms for this project are unconfirmed. No vendor was contacted or proprietary dependency adopted. License terms
Windows IMAPI: Microsoft's documentation explicitly describes UDF multisession on sequential Blu-ray media, including a UDF 2.50 layout. Its BD-R append workflow imports the existing filesystem before adding files; automatic import prefers UDF on a hybrid disc. This is a concrete alternative authoring/burning API, but requires a Windows writing environment and therefore changes the existing Linux workflow. No Windows environment or drive passthrough was tested. Layout BD-R import and append workflow
Open-source Linux development: current schilytools mkisofs/udf.c still sets
its partition origin at the new file-set descriptor and computes file addresses
by subtracting that origin from their stored block addresses. Imported earlier
extents therefore require a deliberate partition/addressing design. This is a
source-based diagnosis of a development obstacle, not proof of a one-line fix.
Updating a revision field alone cannot implement UDF 2.50. Extending mkisofs would
also retain its ISO9660 output unless separately changed, which is acceptable only
if UDF becomes cumulative as well.
Current source
NetBSD's kernel writer is another research lead, but its manual explicitly labels Blu-ray writing experimental. Current NetBSD makefs can create populated UDF images including revision 2.50; that alone does not demonstrate previous-session import. Neither is presently a proven replacement for this application's writer. NetBSD mount_udf Current makefs documentation source
Other authoring leads: pycdlib exposes UDF image-authoring APIs, but this review did not establish a ready optical append workflow that imports previous sessions and reuses their on-disc payload extents. Its ability to create a UDF image alone does not close that gap. This is an unproven candidate, not a finding that such an extension would be impossible. API documentation Project source
The proprietary Linux SDK is not being adopted for this open-source project. An open-source Linux solution would require a separate feasibility effort unless a suitable existing author is found later. Windows IMAPI remains documented here as evidence that cumulative UDF multisession is implementable, not as the selected workflow.
A user-reported Panasonic playback test establishes that the current hybrid discs work with the tested MKVs. The UB820 manual lists MKV on BD-R/BD-R DL but does not name the filesystem selected from a hybrid disc or guarantee UDF multisession behavior. Pure-UDF first-session playback and behavior after additions still need testing. UB820 manual, printed pages 6 and 41
The ISO9660 bridge costs descriptors, directory records, path tables and, in raw mode, Rock Ridge metadata. Payload is stored once. Savings depend on file/directory counts and are generally modest for large MKVs or a few DAR slices. A read-only inspection of existing local comparison images identified 34 KiB of allocated ISO9660/Rock Ridge structures for 123 raw files in four directories, and 12 KiB for five DAR-layout files in two directories. Counts include the root directory. These are example metadata footprints, not exact savings from changing writers: a different UDF layout, alignment or revision can change other overhead too.
The raw example's breakdown was 4 KiB of descriptors, 4 KiB of path tables, 24 KiB of directory blocks and 2 KiB of Rock Ridge continuation storage. The DAR example was 4 KiB each for descriptors, path tables and directory blocks. These local comparison fixtures and the inspection were not a multi-session burn test; the fixtures are not part of the published repository. Treat the measurements as illustrations, not a universal per-file constant or reproducible benchmark suite.
No conclusion about which filesystem the Panasonic actually chose can be drawn from successful playback of the hybrid disc alone. Also, normal Linux mounting does not automatically union independent session trees: the selected filesystem must itself describe the full namespace. A reader's support for a recent UDF revision does not by itself establish its support for selecting the latest session.
ddrescue copies a selected byte domain; it does not inherently mean "first session only." Three issues must be distinguished: which recorded blocks the drive exposes, which range the copy operation reads, and which filesystem view the image reader selects. A complete image can still appear to contain only old files if the wrong filesystem structures are selected. GNU ddrescue manual
A reliable recovery procedure would have to preserve absolute 2048-byte logical block addresses (LBAs), capture track/session geometry, and determine every readable recorded range. A ddrescue domain/mapfile could restrict reads to those ranges. Session gaps must not automatically be classified as lost payload. If the block device exposes only an earlier recorded extent, an alternative readable path or range-based procedure would need to be proven on the actual hardware.
A flat image does not preserve an optical drive's session table. Recovery therefore
also needs a demonstrated way to select the latest valid UDF structures in the
full-address image, including anchor and last-block locations where necessary.
Linux offers UDF recovery mount options, but their use on the proposed output was
not tested. Session numbers and LBA offsets are different; ISO9660 sbsector or
xorriso header-patching recipes are not interchangeable with UDF recovery.
Linux UDF mount options
A fragment containing only the next session may reference old extents and need not be independently mountable. Reconstructing a disc image must retain those extents; filling their addresses with zeros cannot demonstrate successful recovery.
These are requirements for a future solution, not a validated rescue recipe for arbitrary multisession discs. Normal bd-archiver burning remains single-session.
The research considered new BD-R discs in sequential recording mode and additive raw sessions first. Replacing/deleting existing files, extending existing hybrid discs, and adding DAR append support were separate scope questions. A VAT writer is not mandatory if another standards-conforming UDF layout can reference earlier extents. Independent session trees that users must mount separately would not provide the requested cumulative Linux view.
The following work explains why this is more than adding a burner flag. It is not a roadmap or a commitment to implement the feature.
A filesystem author would import the previous committed namespace, retain old payload at its recorded LBAs, and produce only new data plus the metadata needed to expose the combined tree. Planning, size measurement and byte emission must use the same layout, UDF revision, alignment and closure budget.
Disc folders and optional image output both need an explicit format contract,
source-change checks, and hard padded-write capacity gates. Streaming and scratch
space requirements must be evaluated so a backend change does not silently add
another full payload copy. Pure UDF could still be stored in an image named .iso;
removing ISO9660 is different from removing image output.
Unicode, large files, empty entries, timestamps and intended permissions need validation. UDF and Rock Ridge do not necessarily expose identical ownership and permission behavior. Volume-label rules would depend on the selected filesystem; unrelated archive-name constraints would remain separate. Shared authoring changes would affect both raw and DAR creation even if append were initially raw-only. Existing discs and prepared manifests would need an explicit compatibility policy.
Media inspection would need track-scoped profile/status, completed and incomplete sessions, the next writable LBA, remaining writable blocks, recorded extent and formatting mode. Completed-track size cannot be treated as remaining capacity. Alignment and session-closure overhead require actual backend measurements rather than the earlier design's assumed fixed allowance.
Prepared additions must be bound to disc identity, prior manifest digest, commit identifier and geometry, then revalidated immediately before writing. Matching the volume label alone cannot detect a swapped disc or an intervening write. Session closure must leave the medium appendable. Existing protections such as exclusive access, process error handling, two-press cancellation, cache invalidation, reinsertion and post-burn verification would need equivalent behavior.
Each addition needs immutable checksums and its own designated PAR2 recovery set;
a cumulative manifest must reference every committed addition. New data should
not require regenerating recovery for all earlier payload. Payload files named
.par2 must remain ordinary data unless designated as recovery metadata.
An initial additive design would merge directories and reject file-path collisions. Automatic PAR2 sizing would require a per-addition budget or reserved remainder; otherwise a small first batch could consume the available space as recovery data. The preview must show payload, recovery, filesystem/session overhead, bytes written now and space remaining for later additions.
Verification must establish that the expected latest commit is visible before checking data. It must cover all additions, missing metadata and mixed protected and unprotected contents. Successfully verifying an earlier snapshot cannot count as a successful later append. Partial writes and damaged latest descriptors must be detected, with recovery able to select a previous valid commit without reporting the incomplete disc as fully healthy.
DAR append would additionally need generation/chain discovery and extraction tests for several generations on one disc and sets spanning multiple discs. Packing unburned contents remains a separate operation. Any actual implementation would also require updated CLI, dependency, Docker, layout, verification, recovery and on-disc usage documentation.
- A pinned, distributable open-source toolchain and a proven UDF author, not just a formatter or raw optical writer.
- At least three sequential additions containing Unicode names, nested and empty directories, empty files, a file over 4 GiB and additions to an existing directory. Independent validation of descriptor checksums, partition-relative addresses, anchors and end-of-session placement, with full-file hash comparisons.
- Tests explicitly reading UDF so a working ISO9660 bridge cannot hide stale UDF. For pure UDF output, confirmation that no ISO9660 filesystem is present.
- Actual BD-R burns, reinsertion and normal Linux mounting after every addition, with both old and new files intact. BD-RE results alone cannot validate sequential BD-R. Drive, firmware, media capacity, kernel and tool versions must be recorded; single-layer results cannot simply be extrapolated to BDXL.
- UB820 playback checks of old and new compatible files after each addition, and observations on other readers/platforms where available. Untested combinations and device-specific session-selection limits must be identified.
- Full recovery of all committed files without the original source, preparation directory or local session log, including tests of damaged latest metadata.
- Meaningful failure tests for incorrect write addresses, swapped discs, stale manifests, capacity/alignment boundaries, incomplete writes, missing metadata and false success from an earlier mounted view; plus the application test suite.
Until these conditions are met, neither a reliable total implementation estimate nor a production-readiness claim is justified. Multisession remains unsupported and is not planned for the foreseeable future.
See also: Burning · Verification · Storage and layout · Incrementals and packing
Getting started
Create archives
Use your archives
Reference