bugGNU Octave - Bugs: bug #45422, GUI Editor does not warn if file...


bug #45422: GUI Editor does not warn if file could not be saved

Submitted by:  Richard <crobar>
Submitted on:  Sat 27 Jun 2015 10:16:45 AM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Richard Crozier Open/Closed:  Closed
Release:  4.0.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)

Thu 02 Jul 2015 02:27:51 PM UTC, comment #11: 

Ok, I found the original bug report, I am closing this as a duplicate of bug #41278. The GUI does warn if a file can't be saved, the problem is the behavior of Octave on read-only files with the default configuration, which is bug #41278. Thanks for bringing this to our attention again.

Mike Miller <mtmiller>
Project Administrator
Thu 02 Jul 2015 02:23:56 PM UTC, comment #10: 

I think issuing a warning, or displaying a message if edit is actually opening a copy would be useful in this case. It's only the silence which is a problem.

Richard <crobar>
Thu 02 Jul 2015 01:22:28 PM UTC, comment #9: 

Ok, thanks for the reminder, I forgot about that feature of the edit function. This is not the GUI but rather the edit function making a copy of read-only files by default. If you open a file in the editor tab using the toolbar buttons, you shouldn't see this feature.

This may already be reported as a request to change edit's default behavior, it may have made sense to someone at one time but maybe not anymore. If I can find another bug report I'll close this one as a duplicate.

To get edit to edit all files in place whether they are writeable by you or not, run the following at the prompt:

octave:1> edit home .
octave:2> edit editinplace true

I think this will make edit more Matlab-compatible and should probably be the default settings going forward. And you should now see an error message saying that the file can't be saved.

Mike Miller <mtmiller>
Project Administrator
Thu 02 Jul 2015 10:22:27 AM UTC, comment #8: 

So to be clear, the bug is actually that the gui silently creates a copy of non-writeable files.

Richard <crobar>
Thu 02 Jul 2015 10:18:39 AM UTC, comment #7: 

I mean


Richard <crobar>
Thu 02 Jul 2015 10:17:54 AM UTC, comment #6: 

The reason it is not warning is that the file opened when you open fstab is a copy placed somewhere writeable, and not actually fstab. In my case it is placed in ~/octavefstab

Richard <crobar>
Wed 01 Jul 2015 04:26:41 PM UTC, comment #5: 

OK.  You'll have to experiment a bit on your system with regard to the manner in which a file opens.  I've attached a little diff patch to print out some file modes if the file opens in an unexpected manner.

The open mode codes are here:


There doesn't appear to be anything in the documentation explaining that the file should open exactly as requested.  It might be on your system that, although the request is QIODevice::WriteOnly, the file does open but with QIODevice::ReadOnly.  Whereas on my system perhaps the file does not open.  If that is the case, then you'll need to change the code slightly, something like:

  if (!file.open (QIODevice::WriteOnly) ||
      !(file.openMode () & QIODevice::WriteOnly))

(file #34355)

Dan Sebald <sebald>
Wed 01 Jul 2015 02:05:57 PM UTC, comment #4: 

No, the same behavior persists in the development version. The editor looks like it has saved the file but it hasn't.

Mike Miller <mtmiller>
Project Administrator
Wed 01 Jul 2015 08:35:18 AM UTC, comment #3: 

I should note that I just tested the dialog box warning behavior at exit, and that should be changed slightly.  If one exits and, when asked, attempts to save an unsaved file that fails to save successfully the dialog box appears but then immediately disappears and the program exits.  The user should really have the option of canceling the exit and saving the file under a different name.

But hold off on attempting to fix this part of it because there is a bigger changeset in the works for exiting more gracefully:


and that changeset may fix this behavior as a consequence.

Dan Sebald <sebald>
Wed 01 Jul 2015 05:42:13 AM UTC, comment #2: 

The development version appears to be working for me (linux).  I see a dialog box warning:

Could not open file /home/sebald/octave/rootjunk.m for write:
Permission denied.

However, I don't immediately see any type of log report indicating this was fixed since the time of 4.0 release.  So, this could be something specific to the version of Qt.  Try the current development version, I guess.

Dan Sebald <sebald>
Tue 30 Jun 2015 01:32:54 PM UTC, comment #1: 

Thanks for your bug report. Confirmed here with a different example. Since a lot of developers do have permission to edit all function files, I did the following:

octave:1> cd /etc
octave:2> edit fstab

Make changes to the file in the editor and save. The tab title updates to indicate that the file was saved, the file contents are still modified, but the file itself has not been written.

Mike Miller <mtmiller>
Project Administrator
Sat 27 Jun 2015 10:16:45 AM UTC, original submission:  

If you open a file in the editor for which you do not have the correct file permissions to edit (e.g. a built in function), make changes, and save it, the editor acts as though the changes have been saved, but they have not.

Steps to reproduce:

Using installed Octave as normal user (not root)

edit mex

edit the file
save it (editor acts as though save was successful)
close mex.m

edit mex

Note changes not saved

The editor should warn when saving a file fails for some reason.

Richard <crobar>


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

Attach Files:

Attached Files
file #34355:  check_open_setting_djs2015jul01.diff added by sebald (1KiB - application/octet-stream)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by crobar (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-02 mtmiller Open/ClosedOpen => Closed
        Dependencies- => Depends on bugs #41278
    2015-07-02 mtmiller StatusConfirmed => Duplicate
    2015-07-01 sebald Attached File- => Added check_open_setting_djs2015jul01.diff, #34355
    2015-06-30 mtmiller Item GroupOther => Incorrect Result
        StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5