[FIXED] Ticket #4098 - Data loss on close

[jnxd]

If one clicks "save anyway", LO will save the file in the same exact path, creating any missing folders.

It seems to me this is the best behavior.

Seems like the best bet. I'll just need to see where I can put the recursive mkdir logic.

It is certainly not standard behavior to change the name of a folder while working on an open file.

Then again that's what testing is for: corner cases.

[GeneFC]

Being easily distracted is not a crime

Sorry, I tried to keep my comments neutral to avoid accusing anyone of a "crime".

Stuff happens.

At the same time I believe almost anyone would agree this is not "standard behavior".

That does not change the need for a proper fix, but in my thinking it does change (reduce) the urgency.

The fix I suggested does not require the program to guess at what the user intended.

Gene

[TheMarkster]

I think what should happen is FreeCAD should not go ahead and close when there was an error saving the file. In the issue I filed I wasn't renaming folders. For some reason FreeCAD was failing in attempting to rename the temp file to the FCStd file.

https://tracker.freecadweb.org/view.php?id=0004098

When I open that folder I see multiple files in the form of GoProMount.FCStd.long-guid-sequence-of-letters-and-numbers. The project file: GoProMount.FCStd does not contain the latest changes, which instead are (presumably) in the latest guid file.

The workaround for this is to delete all of those files (or just the GoProMount.FCStd file) and try again. No warnings and the file gets updated that way (until I need to save it again). This is only an inconvenience for me because I understand the workaround and how to recover my data, but most users will not understand. Their data is there, but might as well not be there because they won't know.

There is something failing for some reason during this process of creating the temporary guid file and renaming it to the project file.

The worst part of this is if I exit FreeCAD with unsaved changes and elect to save the changes on exit the save fails and yet FreeCAD still exits without any warning message. FreeCAD should not exit. It should remain open so the user can save as the file to another location or at least be told his data is safe in this new guid file, which must be renamed manually.

[jnxd]

I think what should happen is FreeCAD should not go ahead and close when there was an error saving the file. In the issue I filed I wasn't renaming folders. For some reason FreeCAD was failing in attempting to rename the temp file to the FCStd file.

Do you still have the same issue? You mentioned that it wasn't completely reproducible.

[jnxd]

PR to address this issue: https://github.com/FreeCAD/FreeCAD/pull/4996. Be mindful that the file still closes if saving is aborted. Apparently not: we need to figure out what exactly is supposed to be returned by Gui::Document::save(). I wrongly assumed true if save went through and false otherwise, but it is still true if an exception occurs, and eventually the file closes because of that.

Leaving the PR as a draft for now.

[TheMarkster]

Do you still have the same issue? You mentioned that it wasn't completely reproducible.

No, it was only with that one file for some reason. Kisolre has found a way that (I haven't tried it) is reproducible -- by renaming the folder the file gets saved to.

[jnxd]

Do you still have the same issue? You mentioned that it wasn't completely reproducible.

No, it was only with that one file for some reason. Kisolre has found a way that (I haven't tried it) is reproducible -- by renaming the folder the file gets saved to.

Oh Kisolre's method is equivalent to the folder being deleted: a folder by the desired name does not exist.

[jnxd]

I guess I'm done with the PR. Now to wait for people to break it.

[uwestoehr]

I guess I'm done with the PR. Now to wait for people to break it.

The PR was merged. Is issue #4098 partially or completely fixed now?

[jnxd]

I guess I'm done with the PR. Now to wait for people to break it.

The PR was merged. Is issue #4098 partially or completely fixed now?

I guess it's pretty much as complete as can be.