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.
|
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.
|
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:
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.
|
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.
|
Thu 02 Jul 2015 10:18:39 AM UTC, comment #7:
I mean
|
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
|
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:
http://doc.qt.io/qt-4.8/qiodevice.html#OpenModeFlag-enum
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:
(file #34355)
|
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.
|
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:
https://savannah.gnu.org/bugs/?44485
and that changeset may fix this behavior as a consequence.
|
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.
|
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:
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.
|
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 the file
save it (editor acts as though save was successful)
close mex.m
Note changes not saved
The editor should warn when saving a file fails for some reason.
|