OMEdit corrupts files

[massimo ceraolo]

I've been working with one-file packages with OMEdit for a lot of time, recently.
OM version: alpha1 64 bit for windows.

In two occasions suddenly the file containing my models lost the majority of its contents, and, while the model tree was still visible in the Model Browser, many models appeared empty when seen in Text View.
This is an awful event, since one looses everything written since the last time he copied his file to a safe place.

I think we should do two things:
1) mitigate the effects of this dramatic event
2) activate a way to find and fix the cause fast.

Point 1). Maybe we could add a feature so that every time one saves a file, a twin file, e.g. with the extension "bak" is created with the previous version.

Point 2) occurence of this event can be detected. In fact when a model name "MyModel" is present in the Libraries Browser, at least "model MyModel end MyModel;" should be present in the code. So if we try to view (e.g. in text view) a model whose name exists in Libraries Browser, and his code is empty, OMEdit can understand that corruption has occurred. In this case it could display the dialog similar to the one we already have to send a crash report, to send a "corruption report". While this report is sent, the user can be prompted to check his files and the corresponding "bak" versions. The corruption report should contain useful info to replicate the corruption, and then to fix the issue.

[massimo ceraolo]

Can someone have a look at this ticket?
I really think that this corruption, if occurs to some that tries OM for classrooms or for industrial usage, can jeopadrise its very adoption.

[Francesco Casella]

Replying to ceraolo:

I've been working with one-file packages with OMEdit for a lot of time, recently.
OM version: alpha1 64 bit for windows.

In two occasions suddenly the file containing my models lost the majority of its contents, and, while the model tree was still visible in the Model Browser, many models appeared empty when seen in Text View.
This is an awful event, since one looses everything written since the last time he copied his file to a safe place.

I think we should do two things:
1) mitigate the effects of this dramatic event
2) activate a way to find and fix the cause fast.

Point 1). Maybe we could add a feature so that every time one saves a file, a twin file, e.g. with the extension "bak" is created with the previous version.

I'm not sure this is a good idea, particularly if you use revision control, because you end up with randomly cluttered directories.

IMHO, the only way to safeguard yourself against this type of events is to use a revision control system, and commit often. Then, you have the complete history of all files always at hand, without ugly .bak or .tmp files, and with all tools like diff and merge at hand. Using an RCS has also a lot of other benefits. We already have some integration in the GUI to Git, maybe we should push this further. For example, one could have a local Git repository and use it for this purpose, even without the need of going online. One may even stash changes automatically to the local repository every time anything is saved, so that a complete history is available.

Point 2) occurence of this event can be detected. In fact when a model name "MyModel" is present in the Libraries Browser, at least "model MyModel end MyModel;" should be present in the code. So if we try to view (e.g. in text view) a model whose name exists in Libraries Browser, and his code is empty, OMEdit can understand that corruption has occurred. In this case it could display the dialog similar to the one we already have to send a crash report, to send a "corruption report". While this report is sent, the user can be prompted to check his files and the corresponding "bak" versions. The corruption report should contain useful info to replicate the corruption, and then to fix the issue.

If this kind of error happens often, this could be a good idea.

In the meantime, in the unfortunate event of this happening again, I would invite you to locate the omeditcommunication.log file in OMEdit's working directory, zip it and attach it to this ticket. This may help a lot understanding the cause of the problem.

[massimo ceraolo]

If this kind of error happens often, this could be a good idea.

In the meantime, in the unfortunate event of this happening again, I would invite you to locate the omeditcommunication.log file in OMEdit's working directory, zip it and attach it to this ticket. This may help a lot understanding the cause of the problem.

I will do so.
This corruption happened to me twice, last July while I was working continuously to prepare my OMWebbook chapter.
We will see what happens at the next opportunity I will have to use OM for very long periods continuously.
I must say that since, since then, no other people has mentioned any similar behaviour, this is not so frequent and probable.

[massimo ceraolo]

Now I can replicate the generation of a very strange situation that causes file corruption.
I will therefore change this ticket's priority to blocking.
Consider the following package:

within ;
package IssueDel
  package One
    model First
      Real x, y;
    equation
        x+y=1;
        x-y=0;
    end First;

    model Second
      Real x, y;
    equation
        x+y=1;
        x-y=0;
    end Second;
  end One;

  package Two
    model First
      Real x, y;
    equation
        x+y=1;
        x-y=0;
    end First;

    model Second
      Real x, y;
    equation
        x+y=1;
        x-y=0;
    end Second;
  end Two;
end IssueDel;

1) load in OMEdit
2) while in Text view double-click on sub-package ONE => the code is displayed
3) right-click on One and select "delete" the subpackage One is deleted
4) double-click on Two => a strange window without text, starting from row 19 can be seen (see attached png)

If, at this point one saves the file and exits, the resulting mo file is correct:

within ;
package IssueDel
  package Two
    model First
      Real x, y;
    equation
      x + y = 1;
      x - y = 0;
    end First;

    model Second
      Real x, y;
    equation
      x + y = 1;
      x - y = 0;
    end Second;
  end Two;
end IssueDel;

But if one continues working in this unstable situation, file corruption occurs. I don't try to replicate corruption because the above procedure should be sufficient to reproduce and solve the issue.

[Per Östlund]

This should hopefully be fixed in r9743a1ae.

The issue was that line numbers weren't updated when a class was deleted, so OMEdit thought that all the other classes were still at their old positions and would thus load the wrong part of the file. My fix simply reloads the file when a class is deleted. I don't usually work on the OMEdit code though, so perhaps adeas31 has a better solution when he's back.

[Francesco Casella]

Please also merge this on 1.12.0 beta, so it will make it in the forthcoming release.

[Adeel Asghar]

The solution was fine but was redundant as we are doing exactly the same thing after few lines but with the wrong instance. I have fixed it now in 98496e5/OMEdit.

The fix is also moved to 1.12 maintenance branch.

[Francesco Casella]

@ceraolo, can you please check that this is ok (using the nightly build) and if so close the ticket?

Thanks!

[massimo ceraolo]

The issue is fixed.
No need to close the ticket (it is already closed).

[Francesco Casella]

Replying to ceraolo:

The issue is fixed.
No need to close the ticket (it is already closed).

Sorry, I overlooked that :)

Thanks for checking!

[anonymous]

Hello,

I just had the very exact problem in OMEdit 1.3. Is it eliminated?

[Adeel Asghar]

The issue described in this ticket was fixed for 1.12 so 1.13 should work fine.
The title is very generic and perhaps you don't have the same exact issue. Please create a new ticket with some more description about the problem.