#376 "Error: cannot write the output file" when Artist string is very long

[James SF DeLaHunt]

Test versions and environment
X Lossless Decoder version 20151214 (149.1)
Mac OS X 10.10.5
100% reproducible

To reproduce the bug
Change XLD Preferences... CDDB... Preferred Service to "MusicBrainz".
Change XLD Preferences... File Naming... Format of filename to "Custom". And fill in %A/%T/%D%n. %t as the format string.
Open a CD from a Release which has a very long Release Artist name. I used Matthäus-Passion. Any one of the 3 discs demonstrates the error.
XLD displays a Detecting Pregap dialogue, as expected.
XLD displays an Audio CD window, as expected.
XLD displays a Multiple Matches dialogue. This is as expected and not related to the bug, I believe. Select "2: Matthäus-Passion (2007 Warner Classics…MusicBrainz) ", though either demonstrates the bug.
Click on the Extract button. XLD starts the ripping process.

Observed behaviour
There is a flick of activity in the CD drive. Then the drive immediately ejects the CD.
The Progress window opens. The Progress window reads:

0201. Matthäus-Passion
Error: cannot write the output file

The Log window opens. The contents are in the attached file, XLD long name error log 2016-08.txt. The most important entries are:

X Lossless Decoder version 20151214 (149.1)

XLD extraction logfile from 2016-08-26 22:57:33 -0700

Johann Sebastian Bach; Christoph Prégardien, Matthias Goerne, Christine Schäfer, Dorothea Röschmann, Bernarda Fink, Elisabeth von Magnus, Michael Schade, Markus Schäfer, Dietrich Henschel, Oliver Widmer, Arnold Schönberg Chor, Wiener Sängerknaben, Concentus Musicus Wien, Nikolaus Harnoncourt / Matthäus-Passion
....
AccurateRip Summary (DiscID: 00393982-047fa493-7a0e451c)
        ->All tracks accurately ripped.
....
No errors occurred

End of status report

The extraction fails.
Afterwards, a directory with this name is found in the target directory:

Johann Sebastian Bach; Christoph Prégardien, Matthias Goerne, Christine Schäfer, Dorothea Röschmann, Bernarda Fink, Elisabeth von Magnus, Michael Schade, Markus Schäfer, Dietrich Henschel, Oliver Widmer, Arnold Schönberg Chor/

Expected behaviour
I would expect any of these 3 behaviours. #3 is my preference.
Option 1:
XLD truncates the release artist (and all other filename format values) to be short enough for directory name limits.
XLD makes a note in the Log that it did this truncation, and shows the format value before and after truncation.
Extraction completes successfully.

Option 2:
XLD examines the filename after substituting all the filename format values. It detects the path separation character, and breaks the filename into subdirectory names and a final base name. It checks a) that each segment of the path is short enough to work, b) that the overall path is short enough to work, and c) that the path has a small enough number of segments to work.
XLD truncates the path elements if it needs to.
XLD makes a note in the Log that it did this truncation, and shows the format value before and after truncation.
Extraction completes successfully.

Option 3:
XLD fails to check the filename after substituting, and as a result it is unable to use the resulting path name.
XLD displays an alert box saying, "Error: cannot write the output file" or a similar message.
XLD does not display the error message in the Progress window.
XLD displays the error message in the Log.
The Log does not say, after a failure like this, "All tracks accurately ripped."
The Log does not say, after a failure like this, "No errors occurred."

Discussion

This particular Release, Matthäus-Passion, has an unusually long Release Artist name. It combines the names of one composer, 11 musicians, and 3 groups. It is 292 characters long (maybe more UTF-16 code units, if the accents are different code units than the base letters).

The directory left over in the target directory has a name 230 characters long. I suspect this is the OS limit on Mac OS. Thus I suspect XLD attempted to write a file with a fatally-long directory name in the path, the OS truncated the directory name, XLD did not notice the truncation, then XLD attempted to read back from its path, and the OS of course had no file at that unusable path.

The Filename Format string, %A/%T/%D%n. %t, uses the Release Artist (%A), the Release Title (%T), and the Track Name (%t) as directory and file names. The OS imposes maximum limits on directory and file names. I suspect MusicBrainz does not make guarantees about maximum lengths for Release Artist, Release Title, and Track Name. Thus XLD has the responsibility to check for excessively long strings from MusicBrainz.

XLD permits path separators (/) in the Filename Format string. Thus, it is best if XLD treats the resulting filename as a path when checking it for correctness.

(Not part of this bug, but it would be interesting to check that XLD behaves well when a MusicBrainz string contains a / character!)

I would prefer XLD to detect length problems, adjust the filename, and try to continue. I can accept a clear error message and a clean failure. Right now, I think XLD does neither.

It is very misleading for XLD to have log messages like "All tracks accurately ripped." and "No errors occurred.", when a fatal error occurred, and no tracks were ripped at all. XLD should generate a more accurate and helpful Log.

Workaround
Change the Settings for Filename Format string temporarily, to replace the format code which is getting the fatally long string from MusicBrainz, with constant string. In my case, I changed %A, giving Bach, Johann Sebastian, Concentus Musicus Wien, Nikolaus Harnoncourt/%T/%D%n. %t. After the Release is ripped, change the format string back again.