3

On Ubuntu Linux, I wrote files to a BD-R using growisofs, per:

growisofs -Z /dev/sr0 -R -J -f -graft-points ...

Then I wanted to add more files, but I was not paying enough attention, I ran growisofs with the -Z option again instead of switching to -M. Now when I mount the disc, I only see the files from the second burn. Is there something I can write again to the disc to make both sets of files visible (as if I had correctly used -M the second time)?

I still have all the original source files, so I could simply burn a new disc and do it correctly - i.e. I don't need to get the data to prevent loss. I just hoped there may be a way to not waste the disc since all the data is burnt on there.

Here's the dvd+rw-mediainfo query output:

INQUIRY:                [PIONEER ][BD-RW   BDR-209D][1.31]
GET [CURRENT] CONFIGURATION:
 Mounted Media:         41h, BD-R SRM+POW
 Media ID:              VERBAT/IMe
 Current Write Speed:   12.0x4495=53940KB/s
 Write Speed #0:        12.0x4495=53940KB/s
 Write Speed #1:        10.0x4495=44950KB/s
 Write Speed #2:        8.0x4495=35960KB/s
 Write Speed #3:        6.0x4495=26970KB/s
 Write Speed #4:        4.0x4495=17980KB/s
 Write Speed #5:        2.0x4495=8990KB/s
 Speed Descriptor#0:    00/12088319 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
 Speed Descriptor#1:    00/12088319 R@10.0x4495=44950KB/s W@10.0x4495=44950KB/s
 Speed Descriptor#2:    00/12088319 R@8.0x4495=35960KB/s W@8.0x4495=35960KB/s
 Speed Descriptor#3:    00/12088319 R@6.0x4495=26970KB/s W@6.0x4495=26970KB/s
 Speed Descriptor#4:    00/12088319 R@4.0x4495=17980KB/s W@4.0x4495=17980KB/s
 Speed Descriptor#5:    00/12088319 R@2.0x4495=8990KB/s W@2.0x4495=8990KB/s
POW RESOURCES INFORMATION:
 Remaining Replacements:16843296
 Remaining Map Entries: 0
 Remaining Updates:     0
READ DISC INFORMATION:
 Disc status:           appendable
 Number of Sessions:    1
 State of Last Session: incomplete
 "Next" Track:          1
 Number of Tracks:      2
READ TRACK INFORMATION[#1]:
 Track State:           partial incremental
 Track Start Address:   0*2KB
 Free Blocks:           0*2KB
 Track Size:            10564928*2KB
READ TRACK INFORMATION[#2]:
 Track State:           incomplete incremental
 Track Start Address:   10564928*2KB
 Next Writable Address: 11867264*2KB
 Free Blocks:           221056*2KB
 Track Size:            1523392*2KB
FABRICATED TOC:
 Track#1  :             14@0
 Track#AA :             14@12088320
 Multi-session Info:    #1@0
READ CAPACITY:          12088320*2048=24756879360

The track size of read track #1 (10564928*2KB) is the correct size of the first burn; the track size minus the free blocks size (1523392*2KB - 221056*2KB) is the correct size of the second burn.

user221592
  • 133

1 Answers1

1

There is few chance to make the files from the first session accessible without hiding the ones of the second session.

There are now two ISO 9660 filesystem trees. Each containing only the files of its session. The superblock points to the newer tree, because it was overwritten on the Pseudo-Overwrite formatted BD-R.

By byte level operations you can make the superblock point to the older tree, but then you won't see the newer files.

With -M, growisofs would have let mkisofs (or the compatible replacement program) read the old directory tree and expand it by the new files. It would then have been written to the remaining space on the medium and pointed to by the pseudo-overwritten superblock.

I am not aware of a ISO 9660 production program which would read both trees, merge them, and write the result as third session without writing data files. But only such a manipulation would give hope that the result fits into the remaining 440 MiB of free space.

It seems to be a bug in growisofs that it accepted -Z on an already written BD-R.

Thomas Schmitt
  • 812