Minor trouble loading mat file from Octave 3.2 into Octave 8

I tried to load a mat file that had been created more than 10 years ago. I got this error in Octave 8:

octave:1> load biglist.mat
error: load: unable to determine file format of 'biglist.mat'

The Linux file command indicated it was ASCII text, and the first few lines of the file biglist.mat were:

# Created by Octave 3.2.3, Sun Apr 22 17:48:45 2012 EDT <username@username-computername>
# name: lst
# type: uint32 matrix
# ndims: 2

Since it was Octave’s text format, I tried this next:

octave:1> load -text biglist.mat 

and it worked.

All is well that ends well, and I’m glad it was still readable, but could someone share if these are known quirks for loading mat files saved by such old versions of Octave?

I’m no expert with Octave’s MAT-file support, but it seems like this should be something that would be easy for Octave to auto-detect? Just look at the first few bytes of the file; binary MAT-files have a magic cookie there, and the patterns for # ... and other valid text-format MAT files might be easily recognizable.

Or maybe not? Maybe the leading comments in the text-format MAT-file are optional, so the first few bytes might be text with any byte pattern? Not sure here. At least maybe the error message should say “Maybe this is a text-format MAT-file that you should load with load -text ....”?

I started this thread because it didn’t autodetect for some reason, though forcing it helped matters in this case. It’s the only Octave mat file I have from that era (everything else is gzipped plain text). Wanted to know if there was some change in the save & load default settings but if not, at least in this case, it was easy to work around it.

What happens if you rename the file to “biglist.txt”? I wonder if the auto-detection algorithm is being fooled by the “.mat” extension and expecting a Matlab-formatted “.mat” file when in fact the file is Octave text format.

That does work, yes. I created a new dummy variable and saved it in various formats with various extensions all in current Octave, and those all autodetect properly. Only the 3.2.3-created file needed a hint as to the type. It might be as you suggest, that it gets confused somehow because of the file name, but I can’t see any reason why. Other than the Octave version number / user name / host name all on the first line, there’s no difference in content. Must be an extreme edge-case behavior.

These days I save everything in Octave’s binary format save -binary foo.mat which is much faster anyway, so hopefully this was a one-off problem.