Open Raagaception opened 2 years ago
hi @Raagaception , thanks for submitting this issue - i was able to repro something similar.
my repro - actions taken: 1/ cmd+P -> encrypt files 2/ cmd+P -> decrypt files
end-state: some files missing data or corrupted expected end-state: all files back to their original forms
worse, when i tried closing/reopening the vault as suggested, this did not fix things.
right now it looks like the issue is likely with let stats = fs.statSync(file_path); //must be done before opening the fd or it errors
(link) returning 0
for some reason - i will need to investigate further when i have time
One possibility is that something changed in Electron.
Electron substitutes a tweaked version of node's fs
library, possibly something has changed in this tweaked version over time that now makes this behavior occur. It did not occur when this plugin was first published, and of course the tests still pass (since they use node
from the command line).
For now my suggestion is to not use the plugin given file corruption risks.
If you have time to investigate a fix and submit a PR that would be appreciated! i do not have a timeline for when i will be available to work on this next, thanks
For now my suggestion is to not use the plugin given file corruption risks.
Yep, I stopped using the plugin altogether because despite restarting vault every time before using it, some files still do never get decrypted randomly. It is a fine concept, but too risky to use for me as of now. I suggest you put a huge warning on the releases page about this until it gets fixed, otherwise we might have users losing their data if they aren't careful enough.
If you have time to investigate a fix and submit a PR that would be appreciated!
Unfortunately, I have only surface level coding knowledge, so I might not be able to help. I wish you luck on fixing the issue whenever you can spare the time!
@Raagaception - Oddly enough everything is working fine now for me - i can't get the bug to reproduce.
Can you tell me the exact series of steps you go through to get the bug to trigger, including how many vaults are open etc.?
Only one vault open, and the same steps as in the opening comment of this thread.
Amazing plugin by the way. Very small issue though. Steps to replicate :
1) Open Vault and run encryption command. Works successfully. 2) Run decrypt command without closing the vault. Only a few files get decrypted, because Obsidian hasn't indexed changes yet - hence now, half files are encrypted, half are decrypted in the same vault. 3) Restarting the vault after messing up the vault in step 2 and running the decrypt command again doesn't do anything on my end, it still remains the same.
For me, as of now it's second nature to always restart the vault before running an encrypt/decrypt function. When I forget to do the same, I just restore from a Git backup. If it's non-trivial and possible for you, could the plugin make Obsidian do a force re-index of the entire vault before encryption/decryption commences? It would be a nice quality of life improvement and eliminate the need for restarting vaults entirely. Or yet another (inferior) way to resolve would be making the plugin somehow be able to differentiate between encrypted and normal files, so that if someone partially messes up their vault like in step 2, they can just run decryption on the remaining left out files after re-indexing. Thanks in advance for your patience!