Apparent decade-old bug prevents a Blu-ray disc from being fully written – error 0x80071AC3 examined.

[xio]

This post was originally going to be a question, but upon further examination, I have figured out a likely cause. The error 0x80071AC3 which could occur while copying files to a BD-R (Blu-ray disc recordable) is likely caused by a decade-old bug in the UDF 2.60 live file system driver of Windows, which prevents the metadata track on Blu-ray discs from being fully made use of.

Here is the text of the original post I was going to make, below which is a possible explanation:

The error 0x80071AC3 occured while archiving files onto a single-layer Blu-ray disc (BD-R).

I suspect that the cause of this is that the space on the UDF metadata partition is exhausted. Can an expert confirm this?

Below are some signs that support and contradict this idea.

On BD-R (Blu-ray disc recordable) media, a new feature called "pseudo-overwrite" was introduced. This feature was added to the UDF (universal disk file system) version 2.60, which was made for the Blu-ray disc. As I understand it, instead of appending new sessions where new files and their meta data (file name, time stamps, etc.) are written after the existing data, as is done on CD-R and DVD-R and DVD+R, Blu-ray reserves some space at the beginning for meta data to speed up the reading process, since the list of files is in one centralized location rather than spread out over the entire media, or does not have to be re-written in its entirety for each session. To achieve this, some space is reserved at the beginning. I suspect that this error occured because said space was exhausted.

I don't know of any way to allocate a larger space for the meta data area. Perhaps I will create a new thread for it, except if someone posts a method here, for which I would be thankful.

A sign that contradicts this idea is that the first non-resident file starts at sector 549888, and the blocks 72000 to 549887 are just null bytes, suggesting it is unallocated space. I tested this by searching for the hexadecimal value "01" in HxD starting after sector 71999. "Resident" means that the file is small enough that it can be housed directly into the file table rather than being written "out there" in the data area, which, for reference, is a feature the default Windows file system NTFS has as well but FAT32 and exFAT do not. However, it also seems unlikely to be a co-incidence that the last written sector within the data area happens to be 71999. If the last written block in the meta data track were something random such as 72237, the likelihood of some hardware-based error having occured would be higher, but it is exactly 71999.

This is the text of the error message that appeared when the process of copying a few thousand files was interrupted, unfortunately in German since that is my system language:

1 unterbrochene Aktion
Aufgrund eines unerwarteten Fehlers können Sie die Datei nicht kopieren. Wenn der Fehler weterhin ausgegeben wird, können Sie mithilfe des Fehlercodes in der Hilfe nach diesem Problem suchen.
Fehler 0x80071AC3: Der Vorgang konnte aufgründ einer Verunreinigung des Volumes nicht abgeschlossen werden. Führen Sie "chkdsk" aus, und wiederholen Sie den Vorgang.

In short, the error says copying was interrupted due to an "unexpected error" with the code 0x80071AC3, that the volume is "unclean", and it wants me to run CHKDSK.

Here is the command line output from CHKDSK /F D:\ . The diacritic characters Ä, Ö, Ü, and ß were not written correctly; "besch„digt" ("beschädigt") means damaged, "Hauptmetadatei" means main meta data, and "Spiegelmetadatei" means mirror meta data.

Der Typ des Dateisystems ist UDF.
Das Feld fr aufgezeichnete Bl”cke im ICB in Block "25312" wird korrigiert.
Die Hauptmetadatei in Block "25312" ist besch„digt.
Das Feld fr aufgezeichnete Bl”cke im ICB in Block "25376" wird korrigiert.
Die Spiegelmetadatei in Block "25376" ist besch„digt.
Die Hauptvolumebeschreibungssequenz ist besch„digt oder nicht lesbar.
Es wird versucht, die Reservevolume-Beschreibungssequenz zu lesen.
Ein logisches Volume konnte nicht mithilfe der Haupt- oder
Reservevolumebeschreibungssequenz definiert werden. Chkdsk wurde abgebrochen.

CHKDSK reports that the main meta data in block 25312 and the mirror meta data in block 25376 are damaged, meaning it is unable to repair the file system, leaving it in a read-only state. This means that the remaining free space on the disc is wasted since it is not useable.

I looked into the sectors 25312 and 25376 using HxD (freeware hex editor), and they sectors contain only null (00) bytes.

The time a file is written to disc is thankfully recorded in the "last access time" attribute, so when sorting the directory by descending last access time, I can examine that the final written file, the third-last, and the fourth-last files are blank (only null bytes), however, strangely, the second-last written file appears as normal. The last written file also lost its last modification date and time, and it is the same as the last access time, meaning the time it was written to disc. If this happened during a move instead of a copy, several files could have been deleted from the source without having been transferred to the target disc. This is why the safe way to transfer files is to copy, compare file count and byte size, and only delete from source if they match.

---

While drafting this post, the same fault occured on a BD-R DL (dual layer) on a different computer, also running Windows 10. Windows made the USB disconnect sound and then the USB connect sound, which I observed since I was in the room of the computer and not absent like the previous time.

This time, the last written sector in the metadata area is 63327, and the first non-resident file sector is 550295, so both are different. The meaning of "resident" is explained inside the quote above, which was originally going to be this post. However, CHKDSK also reports that the main meta data in block 25312 and the mirror meta data in block 25376 are damaged, which are the exact same numbers as in the CHKDSK result from the single-layer Blu-ray disc mentioned in the quote.
The same results occur on a different Blu-ray drive and a different computer with Windows 10, so the common denominator is the Windows UDF driver, which seems to be unable to handle a high number of files (over 10000) reliably.

On optical discs, the written and unwritten parts are visible using the bare eye. On both these discs, there is a writing gap near the beginning, meaning that this part is not written to.

I think a fix in the UDF driver by Microsoft could solve this problem and also make the rest of the space useable again, but I doubt that much about the UDF driver has changed since the days of Windows Vista, where it was introduced into its current form. I presume that it was developed once and barely touched since then. I even doubt that the original developers of the UDF drivers are still working at Microsoft. So all that could fix this is a third-party packet writing software. However, those presumably were barely developed since the Windows Vista era due to its native packet writing support, which usurped third-party software that might not had such bugs. The integration of UDF packet writing since Windows Vista appeared to have rendered third-party software obsolete, but some third-party software might not have this bug.

Another way would be to author and append to Blu-ray discs using conventional multi-session with a software like ImgBurn or InfraRecorder or CDBurnerXP, but that is of course far less convenient than the USB-stick-like file management workflow in Windows Explorer. If I wanted to rename something, it would have to wait for the next writing session.

One could also pack many files into a ZIP or 7-Zip archive, which reduces the file count and hence the usage of the metadata track, and indeed, it makes sense for many small text-based files such as saved pages with resources inside a _files sub folder. But for multimedia (photographs, videos, audio), it is far more convenient to be able to play the files back directly from the media and having a miniature view directly in Windows Explorer, rather than having to extract the files first.