I love this plugin. I’m so glad that the dev already seems to be working on it at https://github.com/delashum/obsidian-checklist-plugin/issues/22
Thanks for finding the issue!
1 Like
Hi @Licat
I see on github that the developer has an updated version (1.0.11), but I can’t re-activate the plugin?
Thanks
We’re waiting for the plugin author to re-submit the plugin so we can take another look just to make sure things are in order.
Thanks. I hope he does it soon as I use it daily 
So in the release notes for 0.11.4 it says
But in the app itself, in the hotkey definitions, it’s worded much more strongly as “reload app without saving”.
So is this command considered very dangerous now? I never knew the cmd/ctrl R was destructive until now…
1 Like
yes, it is destructive. I always told people not to use ctrl-r. Under normal circumstance, you should not use ctrl-r. Only plugin dev, maybe theme dev may need to refresh the app.
Hm. Looks like several people fell afoul of the issue I was chatting w @Licat on discord about, i.e. transactional access to vault file modifications. This is partly a documentation issue, but it would probably help a lot to have an API like vault.modify(file, old, new), where the only way to rewrite an existing file is to pass in the contents you expect it to have on disk. This would be a built-in check against stale or empty cache values, not to mention a lot of race conditions. Then the existing vault.write could be deprecated and phased out.
Optionally, such an API could work by opening the file on disk, locking it, then reading its contents to check, before modifying the contents. (And performance could potentially be improved by only writing from the changed portion… which for the majority of writes – i.e. while someone’s typing – would be at the end of the file.)
1 Like
How much is your computer’s RAM and your vault’s size?
We will add an internal file recovery system in an upcoming release to mitigate these data loss issues.
2 Likes
@WhiteNoise That sounds useful, glad to hear this. I just had another zero-byte file pop up on 0.11.6 with very few plugins enabled. I had recently triggered a reload from the command palette (was working on CSS) but I wasn’t in the middle of editing any data etc. Weird.
You shouldn’t need to reload with css changes, just in case that helps.
i just had another 0-byte file data loss situation, on 0.12.1 with just a few very widely-used plugins enabled. File recovery snapshots only had captured 1 snap and it was basically empty.
@WhiteNoise I don’t know what’s going on here but just wondering if this should really be in the “graveyard” or if there’s any additional debug info I can provide to help track down what’s going on?
Is anyone else still getting these 0byte files / data loss? Am I just extremely lucky?
Here’s a screenshot of file recovery (just the 0 byte version and the one shown which had almost nothing as well)
Here’s the file local APFS snapshots viewed in Time Machine, this has a bit more (that’s what I recovered from), but still was missing some info.
I suggest you decrease the snapshot period.
If you have reproducable steps, open a new bug report.
If you pinpoint a plugin, open a bug report and we will review it.