"inblorb: fatal error: internal error (empty intermediate pathname)"

I’ve wanted to re-release my source code in HTML for a while and finally got around to looking into it this morning. It seems I cannot use this combination in any of my larger projects:

release along with a website.
release along with source text.

Here’s what I get.

Packaging up for Release - Failed

The application ran your source text through the Inform 7 compiler, as usual, and then manufactured the final story file using Inform 6: all of this worked fine. However, the “cblorb” packaging tool then failed to make the actual release of the data out of your project. Its errors are written out on the Console tab.

This almost never happens in normal usage, and is almost certainly the result of a “Release along with…” sentence in the source having asked to do something impossible. For instance, an attempt to release along with cover art will fail if there’s no cover art provided, or it has the wrong filename or is in the wrong place. So the best thing to do is probably to look carefully at any Release instructions in the source, and check them against the documentation.

Having a look at the console, I see

Compiler finished with code 0
C:\Program Files\Inform\Compilers\inblorb
Release.blurb Build\output.gblorb
! inblorb 4 [executing on Friday 27 February 2026 at 11:30.16]
! The blorb spell (safely protect a small object as though in a strong box).
! Release folder: <C:\Users\crank\OneDrive\Documents\Inform\Projects\PWW r3 new regex.materials\Release>
Copy blorb to: [[C:\Users\crank\OneDrive\Documents\Inform\Projects\PWW r3 new regex.materials\Release\Portrait with Wolf.gblorb]]
inblorb: fatal error: internal error (empty intermediate pathname)

Observation: a minimal project releases fine

lab is a room.

release along with source text.
release along with a website.

Observation: despite the failure message, an HTML file is created, but it is incomplete, containing only links/headers that don’t lead anywhere. The process also generates an accurate plain text “source.txt” file.

Could this be caused by some flaw in my project organization/headings?

That error is quite a low-level one, from the depths of the foundation-module in inweb. It’s most likely a bug somewhere in inblorb. The likiest way to find out what would be to send me a copy of the project so I can debug it.

1 Like

OK. If it’s nothing obvious, I’ll try to narrow things down by trimming one of the projects. If that doesn’t get me anywhere, I’ll report back.

1 Like

Maybe related to the bug where Inweb crashes for directories (webs) with trailing slashes in the path.

1 Like

That’s interesting! How is that triggered?

It seems that this problem arises when a heading is not capitalized.

this works

Volume 1 (test)

release along with a website.
release along with source text.

lab is a room.

but this does not

volume 1 (test)

release along with a website.
release along with source text.

lab is a room.

The documentation examples do feature capitalized headings, but I feel that this comes across more as a matter of style than one of technical necessity. I guess it’s debatable whether this is a bug or not.

4 Likes

If it crashes the compiler rather than printing a useful error message, imo that’s definitely a bug! There should never be fatal internal errors, even for nonsensical source code.

4 Likes

That makes sense! I have a Jira account, but I wonder if there is other testing or information that would be useful in a report. I’m a little out of my depth here.

If you know the cause (lowercase headings) and can provide a minimal example (a short file that always causes the crash, like in your last post), that should be plenty.

1 Like

OK, done!

3 Likes

Yes, absolutely. It might be debatable about whether uncapitalized headings should be allowed, but they shouldn’t cause a crash – it should either work, or print a readable error message that clearly explains why it didn’t work.

Personally, I think it should be allowed. It would be weird if Inform was case-sensitive only in this one place.

Well, Inform-6 is like that :smile:

1 Like

Is that supposed to be an endorsement? I can’t imagine “sometimes case-sensitive” is better than “always case-sensitive” or “always case-insensitive”, other than maybe the case of “case-sensitive only if objects of the same name and different case were explicitly defined” that applies to Inform 7 phrases.

I would take it less as an endorsement and more as snark about Inform 6’s infamously convoluted lexer and parser. (In the sense of parsing source code, not player commands.)

1 Like