Improve Logging where autosave file can't be opened due to corruption
See original GitHub issuePrerequisites
-
Put an X between the brackets on this line if you have done all of the following:
-
Running the latest version of Constellation
-
Attached the Support Package via
Help
>Support Package
-
Checked the FAQs: https://github.com/constellation-app/constellation/wiki/FAQ
-
Checked that your issue isn’t already filed: https://github.com/constellation-app/constellation/issues
-
Checked that there is not already a module that provides the described functionality: https://github.com/constellation-app/constellation/wiki/Catalogue-of-Repositories
-
Description
New functionality has been added to Constellation to improve the experience when there are corruptions in the Autosave, Star or backup files (see #19). When there is a corruption with the Autosaved file and I select to open it, Constellation is opening up the STAR file which is the correct behaviour (as the logic detects an issue with the Autosave file), however the log file is not accurate as it states that the backup file is being opened. In this case the STAR file was opened as the autosaved file could not be.
Steps to Reproduce
SET UP FILES
- To reproduce this issue you need to have the right files in place. Create a graph or open an existing one. Make some changes to it and confirm in your Save location you have a STAR and .BAK file
- Open up the autosave location which is under the userprofile
- Make some changes to the graph, don’t save them. When you have the autosave file and autosave file pointer created, copy them to another location for later use
- Close Constellation. Don’t save the changes to the file.
- Now make a corruption to the autosave file. You can do this by creating a text file that is blank and giving it the same file name as the autosave file.
SET UP SCENARIO
- Copy the corrupt autosave file back into the autosave location along with the autosave pointer
- Open up the graph from File Recent
- Confirm you get a message asking to open up a more recent file (if not, don’t proceed as you won’t get the right log)
- Click OK to open up the more recent file
- Check the STAR file is the one that actually opens
- Check the log files under Help Show logs
Expected behaviour: Log file states that the Autosaved file was attempted to be opened and could not, so the .STAR file was opened
Actual behaviour: The log file states that the .STAR file could not be opened so the backup was opened instead.
Reproduces how often: This can be reproduced for these scenarios which is where there is a corruption with the autosave file and the user selects to open it:
Additional Information
NA
Issue Analytics
- State:
- Created 2 years ago
- Comments:6
Top GitHub Comments
@Delphinus8821 is correct in how this all works. Autosaves have always had a mechanism by which they are basically (if requested) copied over the star file if the user elects to use them. So what hapopens is the autosave overwrites the star and the (original) star overwrites the backup file.
The logs correctly reflect what is happening, what they dont say is that the star file is overwriting the backup and the star file is being overwritten by the autosave.
We could probably add logs for this to make it more obvious to users looking at logs. However the ‘actual behaviour’ is as good as we can get given the orighinal need to open autosave over top of star
I’ve given this a test and it the logs seem fine to me and explain the different scenarios like