Runtime error loading external preference file -- I7 6M62

Can’t find mention of this here or in Mantis. On MacOS 10.12.6 with I7 6M62, attempts to use an external file fail with a runtime error. This used to work.

To reproduce, simply test the “Alien Invasion Part 23” example from the docs:

"Alien Invasion Part 23"
A difficulty is a kind of value. The difficulties are easy, moderate, hard, and fiendish.
Understand "use [difficulty] puzzles" as selecting difficulty. Selecting difficulty is an action 
out of world, applying to one difficulty.
Carry out selecting difficulty: 
    choose row 1 in the Table of Preference Settings; 
    now challenge level entry is difficulty understood; 
    say "Puzzles will be [challenge level entry] from now on."
The File of Preferences is called "prefs".
When play begins: 
    if File of Preferences exists: 
        read File of Preferences into the Table of Preference Settings; 
        choose row 1 in the Table of Preference Settings; 
        say "(The current puzzle difficulty is set to [challenge level entry].)"
Check quitting the game: 
    write File of Preferences from the Table of Preference Settings.
Table of Preference Settings 
challenge level 
easy
The Sewer Junction is a room.

It blows up with this runtime error: “Error handling external file (P48).”

I’ve posted a bug in Mantis: http://inform7.com/mantis/view.php?id=2056.

Any ideas? Thanks in advance.

Dredging up this issue since it has received no attention for a long time yet the problem remains. Worse, Mantis appears to be inoperative now and the posted bug linked above no longer works.

Any ideas what is going on both with external file handling by I7 and with Mantis?

Thanks in advance.

If I use the code exactly as written, it doesn’t compile due to the lack of spacing around the Table of Preference Settings.

If I put a blank line above and below that, then I can successfully run it, and it works as expected – saves the settings if I use moderate puzzles then quit and restart.

I was testing on Windows 6M62 using the default IDE and with WinGit.

Possibly of note is that (as documented) if you’ve saved the file with a different version of the story with more rows or columns in the table, then you’ll get a runtime error when you try to read it back in. Perhaps you did that at some point while testing?

There’s a few other cases that can cause similar errors, such as if the directory where the file is saved contains another file with the same name that was created by a different story project.

There should be another error line telling you what the specific issue is as well.

Many thanks for the reply, Gavin. I believe that this is a MacOS problem since you find it works on Windows and previously worked also on MacOS in an earlier OS version.

The example – put into the source window by I7 via clicking the ‘copy over the source’ icon – compiles just fine. But the game throws the runtime error when quitting as the game attempts to write the “prefs” file. This happens whether there is no prior such file there or if I put an empty file with that name there for I7 to “find.”

You were correct that there is another error line; my bad for omitting it. Here is the full output:

>quit

*** Error on file 'prefs': tried to open a file but failed ***

*** Run-time problem P48: Error handling external file.

Are you sure you want to quit? 

I’d suspect a permissions problem, but I7 is able to write maps to the directory in the examples in Ch 25 of “Writing with Inform.” So it must be something else.

Also, every one of the other such examples fails in the same way – so it’s not just this one.

Also any idea what’s up with Mantis? Pages are simply blank – no request errors, just nothing.

Thanks again!

I tried this on macOS (Catalina 10.15.7) and it works just fine, after adding the requisite line breaks and tabs. It writes the external file prefs.glkdata in the same folder as the project on quit, and reads it again the next time.

EDIT: Attached the project files
Untitled.zip (3.2 KB)

Many thanks, Petter. There’s obviously something borked on my machine – or with MacOS 10.12.6 that I’m still using – since the file you sent shows the same runtime error that mine does. This is truly weird, since I’ve worked through every one of the examples in “Writing with Inform,” and the only ones that won’t run as is are the ones in these chapters about external files (23.13 to 23.15).

Well good to know that it’s not an I7 issue then, or even specifically a Mac thing. Though it’s too bad that I7 doesn’t generate log files that could be examined for errors. No clue how to investigate this further.

Thanks again for your help, Gavin and Petter!

Have you tried it with an interpreter other than the IDE?

When I run it with Git, the .glkdata file is put into the same directory as the .gblorb / .ulx file. When I run it in the IDE, it goes into some other folder that I haven’t actually located as yet (but I didn’t look very hard).

It’s possible that on your system it’s trying to write to some kind of write-protected directory, or otherwise set with special permissions such that the write fails.

I’m not really familiar with MacOS but you could probably run it together with strace to get a log of where it’s trying to write the file and what the underlying OS error was.

At least for me, the Mac IDE has always written external files to the same directory as the .inform project file, so it is possible that the write permissions for that folder is the problem.

It seems that the current restrictive policies in macOS for system permissions were introduced in 10.14, so they should’t affect you on 10.12.

By the way, as you may know, there are several different versions of the macOS IDE for 6M62. Which one are you using?

More thanks to you, Gavin and Petter. I have now confirmed all of your findings:

  • With another MBP running MacOS 10.15.2, the external file is correctly created and read.
  • With the first MBP running MacOS 10.12.6 with a re-installed copy of the latest I7 6M62 from the Inform web site, the external file is also correctly created and read.

So this was definitely an “IT Crowd” “turn it off and on again” situation. I apologize for all the wasted bandwidth for a problem that was entirely local, however strange. I am surprised that the I7 IDE I had installed would choke on only that one function, but I should have figured that out before posting.

Nevertheless, I really appreciate your help!