Hello, I spent hours the day before yesterday classifying my fonts into collections and subcollections. I did only a part of my library, maybe about 1000 or 1500 fonts.
I was planning to continue today with a few more thousands. When I open Fontbase now, huge surprise, most of the classifying work is messed up: most categories have disappeared, almost all subcategories are, most of the remaining are empty, most of the fonts are not classified, some categories I had deleted or renamed are back there. Some categories are still there with fonts, but not many.
I have no idea what happened and lost all motivation to continue, especially if I cannot be sure any new work isn’t going to be lost again.
Could you double check how collection saving happens and make it fail free? And also could you describe how it works, when and how is it saved, etc? I cannot work without categorising the fonts, but I also don’t want to take any more risks.
Hello Nicolas and welcome back
If I may ask something to understand the situation better before providing a proper answer and recommendations: from the parameters you’ve provided at the end most likely you’re using FontBase on two computers and have the root folder set to network location - is this a correct assumption?
Almost: it’s the same computer, with Linux and Windows in dual boot, and the root folder set on a shared internal drive. But in effect, it’s like two computers, yes.
What I figured out since: I believe the laptop might have ran out of battery on the day I did the classification. Does FontBase only save changes when it is closed properly? If so, maybe it would be interesting for safety to save every x minutes, or at every change, every time the window is out of focus, or something like that, to avoid loosing work.
Hello Nicolas, thank you for your reply
Right off the bat - sorry for the type-o’s in my previous post
FontBase does save the changes after they occur, not just on shutdown. The only situation where some data could be lost is when the app crashes (e.g. during a reboot) while the changes are being saved.
If collection auto-sync is enabled, however, the collection data will only be exported to the .json file on proper shutdown or if the export button is pressed. Would you happen to remember if this option was enabled at the time when the original issue occurred?
I do have “Auto-sync collections” enabled… because I want collections to be automatically synchronised? Or is the name of the feature a misnamer? Does it auto-sync even more when it is disabled?
If I understand correctly:
Auto-sync off: collections auto-sync at every change.
Auto-sync on: collections auto-sync on start and close.
I’m a little confused, I’d expect auto-sync off not to sync at all, unless I press some sync button somewhere.
Thank you for the quick reply
Apologies for the confusing explanation in my previous reply
Auto-sync off: collections .json file is left alone, neither updated nor read from automatically. It can still be updated manually at any time.
Auto-sync on: .json file is read from on app startup and every time the file changes, and is written to on app shutdown (unless it crashes).
By “saving the changes after they occur” I meant FontBase data itself, as it stores more data than just this .json file (e.g. font information, activation status etc, settings), sorry again for the confusion.
I understand that this approach might sound non-productive at first. However, as tests showed, saving every single change as it happens and reading the changed file as soon as it changes may introduce some nasty bugs. For example, set off a chain reaction where one user’s app updates the .json file and then all the apps with auto-sync turned on start a possibly infinite loop of import/export/import/export.
Please let me know if this shed at least some more light onto how the process goes.
Thank you and sorry again for the lack of clarity,
Thanks, sorry I didn’t understood first, this is much more clear now, and indeed more in line with how I thought it worked.
So for my use case, I think keeping it on is more adapted here as I do want my two instances to be perfectly in sync all the time. Since the two OSes are on the same computer, they are never running at the same time, so I’m guessing the loop/conflicts cannot occur since only one instance of FontBase can possibly be open at the same time.
I assume the issue was caused by the laptop running out of battery, which somehow messed it up? I’ll finish classifying, export backups of the json as I go just to be safe, and hope it won’t happen again!
The laptop running out of battery and the OS shutting down unexpectedly would have prevented the .json file to be updated on shutdown, yes. Then, when restarting the computer and opening FontBase, the app imported the .json as the auto-sync was on, but, unfortunately, this was the file version that was not updated properly on shutdown, and so the app imported the now obsolete collection data, rewriting the data inside FontBase data storage itself.
Yes, you’re definitely right, using the setup you’re using only one FontBase instance could be running at one point in time. This is relatively less common compared to different people using different FontBase instances at the same time when working together on a project, hence the .json file sync flow prioritisation
