#1

Steps to reproduce

Open a vault on a drive with intermittent connectivity, e.g. a network drive or a virtual volume. Create at least two .md files with content, so that it’s possible to switch between them in the browser. Disconnect the network drive or unmount the virtual disk. Try to access the .md files, switching from one to another - Obsidian will complain and show empty content windows. Connect or mount the volume back, switch between the files again. Obsidian will overwrite files with the contents of empty editor windows - resulting in 0 byte files.

Expected result

Obsidian asks whether to reload the file once it is accessed again after error.
Obsidian warns me before overwriting an existing non-empty file with 0 bytes and gives me an option to avoid this.

Actual result

File was overwritten with 0 bytes. Entire content was lost.

Environment

  • Operating system: Windows 10 Pro
  • Obsidian version: 12.10

Additional information

I just lost a crucial file in a vault as a loss of connectivity happened as I switched files in the browser. Please block all attempts to overwrite non-empty files with 0 bytes, unless this is confirmed by the user.

#2

Did you check the core file recovery plugin to see whether you can recover the data?

#3

I just did. Thanks for pointing this plugin out, I was unaware that it existed.

Unfortunately for the file I lost I only see one final snapshot, 0 bytes long :frowning:

There actually should be more, I did edit the file yesterday before it was gone. It’s not impossible, though, that my edit and the loss happened within one 5 minute interval, before a snapshot was captured.

Still, could you please point me to the location where the snapshots are kept? Perhaps I’ll find or recover something there manually.

#4

They’re kept in indexeddb. If you use obsidian sync that’ll have a history as well.

#5

I understand your issue. I am not sure I consider this a bug or just a use case we don’t cover.
Obsidian warned you that there was a FileSystem problem and we generally have the file recovery plugin for these cases.

I’ll’ think about it.

#6

@przemyt can you take a screen recording of this happening?

#7

@koala - I’m not a sync user. How do I access the indexeddb? I see some binary files in my [User]\AppData\Roaming\obsidian folder that mention my wiped file and some of its content - but I’m not sure how to recover this meaningfully.

@WhiteNoise - imho overwriting existing content with 0 bytes is only a use case if there’s a clear decision from the user to do so. Otherwise, it’s a bug.

In this case, yes, I got a warning about a file system error, but I expected Obsidian to recover from this gracefully, without losing content.

What I’ll do next time in a situation like this is shut down Obsidian right away, make a backup of the vault once the connection is back, then restart Obsidian and recreate any files that get wiped with 0 bytes from the (hopefully) intact backup. But this is a workaround and it’s hardly graceful.

For the recovery plugin - the defaults don’t cut it. I did not edit my file in the last 7 days. Then made an edit shortly before it got wiped with 0 bytes. As result I only have a 0 byte snapshot. Perhaps the plugin could by default remember let’s say minimum 5 most recent snapshots regardless of their age and never treat 0 byte files as valid snapshots?

Screen capture - I’ll look into it.

#8

@koala
Following up on indexeddb - I tried to access it using FastoNoSQL as well as the Plyvel library in Python. The first one crashes when trying to open the db, even though connection tests ok. The second gives an error message about “corrupted compressed block contents” when trying to iterate through keys.

Could indexeddb corruption be the reason for my issue?
Can you recommend any other ways, tools or settings to read the db even partially?
Is there any way to do any kind of a debug dump of the indexeddb using Obsidian?

Any help appreciated :confused:

#9

@WhiteNoise So far no luck with the screen capture, I’m unable to reproduce the content loss. I suspect this could have something to do with the fact that the vault and the lost file was edited after a longer break in activity and my obsidian use. So recovery snapshots timed out, there was an obsidian update as well. That’s not a set of circumstances I can fully reproduce. I’m focusing on attempts to recover content from the indexeddb - and on recreating the file manually in case all else fails.

#10

if you don’t see the snapshot in the list of filerecovery plugin, you won’t find anything in indexdb.

I am gonna closed this BR. if you can repro it, open a new bug report.

I also want to reiterate that we don’t explicitly support network drives because the file watcher doesn’t work there.

#11