[Editor] Autosaves piling up in the level directory
Emral opened this issue · 7 comments
Which component?
Editor
Describe the bug
On the newest builds of the editor, -autosave.lvlx files are created in favour of the old .bak files. Unlike .bak, however, I've been starting to notice these not getting removed and instead making more and more copies. This seems unintended.
To Reproduce
Edit level. Close editor. Discard changes. Edit level. Close editor. Discard changes.
Expected behavior
-autosave files should not be around under any circumstances if the editor was closed cleanly. And if it didnt close cleanly, they should be cleaned up on next closing.
Screenshots
Desktop specs (please complete the following information):
Windows 11
Additional context
Less context, more curiousity, but why was the naming convention changed for them? .bak was more clearly a backup file than these autosaves are. Having them be treated as a different file extension seemed cleaner to me, as Windows gives them a different icon and you can gitignore *.bak easily, something not as easy for -autosave.lvlx and -autosave-0.lvlx.
I think, right, autosave files should be deleted when save requesting or changes discarding, and real reason they should survive is a crash or power surge. Also, I forgot to implement the track of autosave files to autoresume lost levels from their last save point.
These .bak files are temp files that lives for a short time and their purpose is a dodging the disk cache to ensure file is written and it won't die. Autosave is different technology that allows level to survive after power surge where emergency saving (used on crashes) is impossible.
Fixed!
So, I made sure that autosave will be deleted when a user explicitly discards changes. Please test the result and reply, is this fine now or not?
Seems to work!
Regarding performing gitignores, do you think it would make sense to store autosaves in a moondust-internal "autosaves" directory rather than directly in the episode directory? That's how most programs I know handle it, I think, to keep the inner mechanism a bit more "out of the way" of the user.
Without automatically restore functionality, it's no reason to put the autosave away the same directory, otherwise, unknowkedged users will take the serious panic when they "lose" their file and can't figure for autosaves directory. But, when I'll implement the automatical restore of autosaved files (using the same algorithm as I do when restore backuped files after crash), then I'll stop to save autosaves at the same directory.
Ahh, I had assumed the restoration was already automatic. Okay, that makes sense then as an intermediary step. Thanks!
So, the bug itself has been resolved. Described improvement is out of the scope of this issue, so, I close this issue.