bugGNU Octave - Bugs: bug #32750, save in 3.4.0 is not backwards...


bug #32750: save in 3.4.0 is not backwards compatible with load in 3.2.2

Submitted by:  Daniel Arteaga <darteaga>
Submitted on:  Fri 11 Mar 2011 02:46:25 PM UTC  
Category:  None Severity:  1 - Wish
Priority:  3 - Low Item Group:  None
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  3.4.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 22 Jun 2013 03:12:08 PM UTC, comment #7: 

No objections.  Closing report.

Rik <rik5>
Project Administrator
Sat 22 Jun 2013 11:47:51 AM UTC, comment #6: 

Does a bug that is "left in place" have to be "open" ? It seems to me that you can google closed bug reports as well. So it makes sense to close this bug.

Anyone object ?


David Bateman <dbateman>
Project Member
Fri 18 Mar 2011 03:22:10 PM UTC, comment #5: 

It may also simply be impossible to generate a file that can be loaded in previous versions of Octave.

Given our limited resources, I'd rather not complicate things by adding -vN version flags for the Octave save formats.

John W. Eaton <jwe>
Project Administrator
Wed 16 Mar 2011 05:16:16 PM UTC, comment #4: 

Thank you very much for your detailed reply.

I understand that it is sometimes desirable to break the save format, but in this case it would be useful to introduce a new option to the save command like "--octave-legacy: Save in octave  format version <= 3.2". After all, this option already exists for the different Matlab save formats.

Daniel Arteaga <darteaga>
Wed 16 Mar 2011 04:41:02 PM UTC, comment #3: 

I understand that this would be a nice feature to have, but it would also limit future additions to Octave load/save functionality.

By example, Microsoft Word can save in either .doc or .docx format.  The old .doc files can be read by any version of Word, but only later versions of Word can use the extra features in the .docx format.  This is the same situation that Octave has, although we didn't rename the file extension.

I checked your file and when saved in Octave text format under 3.2 it correctly loads under 3.4.  Thus, 3.4 is backwards compatible with older versions of Octave which is critically important for maintaining access to legacy data.  However, to be able to take advantage of some new features (such as range compression) you will need a recent version of Octave.

Incidentally, Matlab got into the same issue which is why there are -v4, -v6, and -v7 flags for loading Matlab data files.

This bug won't be fixed, but the report will be left in place for users who may stumble upon this issue.

Suggested workarounds
1) Upgrade all collaborating users to the same version of Octave.
2) Use a specified file format, such as -v7 or -hdf5, for sharing files between different versions of Octave.

Rik <rik5>
Project Administrator
Mon 14 Mar 2011 11:08:31 AM UTC, comment #2: 

I understand that this might be rather a feature request than a bug, but anyway it is still very inconvenient issue for people using octave for scientific collaboration, each one using slightly different versions.

In the same way as save format tries to be backwards compatible with different Matlab save formats, it would be nice if it was backwards compatible with its own native format.

Daniel Arteaga <darteaga>
Sat 12 Mar 2011 06:37:35 PM UTC, comment #1: 

We don't promise backward compatibility for save formats, so I don't see that this is a bug.

John W. Eaton <jwe>
Project Administrator
Fri 11 Mar 2011 02:46:25 PM UTC, original submission:  

See example file saved in octave 3.4.0, when loading from octave 3.2.2, using native text octave format (no options for save)

As a workaround one can use matlab v7 format.

Daniel Arteaga <darteaga>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #22900:  meta added by darteaga (13KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by darteaga (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-06-22 rik5 Open/ClosedOpen => Closed
    2011-03-16 rik5 Severity3 - Normal => 1 - Wish
        Priority5 - Normal => 3 - Low
        StatusNone => Wont Fix
    2011-03-11 darteaga Attached File- => Added meta, #22900

    Back to the top

    Powered by Savane 3.5