Data loss - 0 byte files (revisited)

First, I suggest you go plugin-less for 4 days.

If you have no problems, I propose this strategy.

  1. Divide your plugins in two disjoint groups A & B with roughly the same numbers of plugins.
  2. Run Obsidian with Group A for 4 days
  • If the bug doesn’t happen, discard A. Run Obsidian with Group B for 4 days
  • If the bug does happen, discard B. Divide the plugins in A in half, say A_1 & B_1. Go to step 2.

You should pinpoint or at least narrow down which plugin is causing the issue.


Hmm. @WhiteNoise your post made me think. I do have a script that backs up my vault every so often. It’s a simple bash script that just tar.gz’s the whole vault to a timestamped archive elsewhere on the disk. Should be totally non-destructive.

But, the last time it ran was at 1:51pm today. Which I note is right before that file got nuked.

Maybe there’s some sort of file-locking that happens when tar is zipping everything up that causes a race condition vs. the file being saved by Obsidian or something…

Sadly, I don’t think that was it.

As you can see from the timestamps in the logs below, my backup script fired at 1:51:31pm, but inside the gzip itself, the file that was nuked has a timestamp of 1:48pm, so the zero’ing out happened minutes before the backup took place.



Sorry this keeps happening; I know it’s frustrating.

whitenoise suggestion to binary search your plugins is a good one.
I know you’ve eliminated your backup script to your satisfaction, but it might be worth trying to run without that as well.

Running lsof | grep Path/To/vault and log the results periodically with a little bash script might be good to try as well. I know you think there are no other processes using your vault files, but it would be good to verify.

Where is the logic in whatever routine sees a 2.14 KB file suddenly become 0 bytes and decide “yeah that must be right, let’s keep the 0 byte version”. Without any notice/log/user confirmation? It makes no sense to me.

Maybe you are not sharing your vault via Dropbox or another Sync service, but what you are describing is not an error case in general. I share my vault among multiple devices and if I zeroed out a file on my laptop, I’d expect that to be reflected on my iPad too without a nag screen.

It’s overwhelmingly likely this is something specific to your setup.
It’s likely small comfort, but I’d be shocked if this was an issue with Obsidian; this is kind of an outlier report, even less than the panics you get. If all else fails, could try running dtruss against obsidian to verify filesystem activity and satisfy yourself that it isn’t over-writing files.

Thanks @pmbauer for trying to help. Really appreciate it. The dude abides! :bowling:

I agree that in general, a file that’s being synced among a group of machines going to zero bytes isn’t necessarily an error condition–if there was intent. I will continue the hunt. I am storing this vault on iCloud Drive, but I believe that’s a fairly common setup. Good suggestions on lsof, I will see if that turns up anything.

I also see that 0.12.3 just got released with a bump to Electron 12. So, will re-test all around on the off chance this was some weird Electron bug.


curious if this might be relevant

@pmbauer Thanks. True, I’d considered that as well. But, I don’t use that “optimize” feature:


Not to say there might not be a bug on Apple’s end (I’ve had my fair share of iCloud problems over the years). When I check right now, all of my files say “Downloaded” though.


I also have a bash script that periodically checks the iCloud database (directly via SQLite) for “stuck” items (you can see these with brctl status also) and reports those errors to me. So I try to stay on top of iCloud shenanigans.

Bigger picture I’m thinking as my vault gets larger and more important, that my best move will be switching to Obsidian Sync and/or a git repo combined with a periodic 1-way sync up to iCloud to be able to view on mobile.

Your experience is a little bit frightening to me. Because I use a script to do the backup: copy the entire vault to a different location and then archive the vault. It is similar to your approach.

Is this method safe?

@luckman212 Does the file become empty while still existing or is the file deleted and recreated as an empty (when you click on wikilink)?

@WhiteNoise The file becomes empty. It is not being deleted. I confirmed this by looking at the file creation (inode-born) timestamp with stat, see below. Also, I am sure that when this has happened, that I’ve just been navigating via the File pane on the left, or through search– not clicking into a Wikilink.

$ stat -Lf 'modified: %Sm%n created: %SB%n' ""
modified: May 11 21:39:46 2021
 created: May 10 12:46:16 2021 <===

Hi all, I think I’m having the same issue and I’ve had this happen about 10 times in the last 3 months – MacOS, Big Sur, v0.12.3

To quote @luckman212:

I don’t have 100% repro steps for this nor do I think I will be able to produce them. I’m more than willing to put in some time and do any sort of testing but I can’t sit here and bang the keys like a monkey until this happens. All I know is it is happening and it’s very unnerving for a “second brain” app to be vaporizing information like this.

In the screenshot below from a few minutes ago, you can see the history of the snapshots as I was working in this note, every 2-3 min. All of a sudden poof there’s a 0 byte version saved.

Here’s my screenshot:

@akaalias Are you storing your vault on iCloud Drive? There may be a pattern emerging…see Text disappearing from notes

Good question, actually Yes, I AM storing my vault on my iCloud Drive!

Thanks. I’m keeping a close eye on this. Recently updated to 11.4 and have not had the data loss in a little while. Still storing my main vault on iCloud. I have my recovery snapshot interval set at 2min. Also doing hourly backups to a separate gzipped folder, and have a Bash daemon that checks for 0byte files every 10 minutes and pops up an alert if any are found.

Good to know that so far it seems to be isolated to iCloud. Anyone else who is experiencing this please post your setup.

If this happens and you have obsidian open, please open the console and see if there are errors.

Have you considered not using iCloud?

I have. See comment above.

But, there are some nice things about having the vault on iCloud, especially if you already pay for additional storage there as I do. I’m interested in getting to the bottom of this bug.

My plan now is to try to use Hammerspoon’s hs.pathwatcher() function to set up a realtime alert if an outside process modifies a file in the vault. If that doesn’t work, I was also looking at trying to fork Sinter and modify it to track filesystem changes to the vault in realtime using Apple’s Endpoint Security Framework.

1 Like

Found this relevant-looking tidbit today:

Michael Tsai - Blog - iCloud Drive Changing Empty Files

Really seems like this is an iCloud issue. Maybe the way Obsidian saves or updates the files is triggering an edge case - that I don’t know. Are atomic file writes being used? If not, maybe something like this could help: write-file-atomic - npm

Is Obsidian Sync the only way to view vault content with the iOS app aside from storing the vault on iCloud? Just trying to understand what the options are.

1 Like

Per the help docs, yes. See section on sync solutions

I have heard of a few using WorkingCopy to locally sync a vault, but haven’t tried it myself.

But if you meant view as in access (Rather than sync, unclear), then you can use the files app on a local, non-iCloud vault, use iaWriter, etc