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.
This has happened to me, too! On MacOS, Big Sur, v0.12.3, with my vault in the special Obsidian folder (generated by the mobile app) in iCloud. I had an issue with note deletion or reversion to a previous save of the note that came up every few minutes until I disconnected and reconnected iCloud on my MacBook. Now I have noticed it happening only 2-3 times in the past few days, in a much less intrusive way where the most data that is lost is only around the last sentence I wrote. Made a post about it here: Note sometimes does not save.
When this bug has come up for me 1) Obsidian won’t allow me to switch to another note from the current note, 2) when I quit Obsidian and reopen the note it has either reverted to a previous save (aka a few lines are lost) or been entirely deleted (this has happened very rarely and only before I re-established iCloud on my MacBook — and weirdly enough seems to only have happened when I select the entire note and Command + C copy it in order to paste the content of the note once I restart Obsidian to restore it).
Very strange bug! It does seem to have something to do with the way iCloud syncs — perhaps the Michael Tsai blog that @luckman212 linked to is onto something.
After some success setting up a complex monitoring system consisting of a LaunchAgent that automatically starts an instance of FileMonitor targeting my vault folder whenever Obsidian is launched (tracking all file activity and parent process with millisecond accuracy) plus a Hammerspoon pathwatcher that automatically logs and pops up alerts in realtime if any 0 byte files are detected in the vault… I thought I was finally on course to track this down.
And then Apple’s endless obfuscation bit me in the rear again: seems that files modified in iCloud on other devices (phone, another laptop etc) trigger file changes in a way that bypasses traditional logging methods. I posted a github issue here and a crosspost on StackExchange as well.
I moved my vault out of iCloud and am just syncing with Syncthing for now. Will probably switch to Obsidian Sync when the mobile app exits beta.
TL;DR— At this point I personally consider iCloud unusable for any important data storage.
I’m following this thread because I also store my vault in iCloud and this is very worrying.
FWIW, I have not had problems, and have been using Obsidian since late last summer (all the time on iCloud). But I only have 1 computer now, so the only other thing I occasionally open my vault with is 1Writer on the iPad. Not sure if that makes a difference.
@atiz This bug is an edge case for sure, so it may not affect everyone. Still trying to figure out how to trigger it. If iCloud is working for you, consider yourself lucky and you don’t necessarily need to stop using it.
As a precaution, you may want to run this command from a Terminal to be sure you have no 0-byte files lurking in there that may have gone unnoticed:
find "$HOME/Library/Mobile Documents" -type f -size 0
@Licat thanks for your help on Discord the other day. I’m going to try to set up a simple Node script as you suggest to see if the behavior is the same as I’m seeing from Obsidian.
It is unsafe to use filehandle.write() multiple times on the same file without waiting for the promise to be resolved (or rejected). For this scenario, use fs.createWriteStream().
I almost hate to ask you, but I assume you’re aware of this and it’s not part of this issue.
Another thought: could a 3rd party plugin that modifies the buffer contents possibly be triggering this to happen, e.g. if the timing was “just right” such that Obsidian was executing it’s periodic scheduled save while the user simultaneously triggered a file-altering action such as a Templater script?
I am aware of that note, as I’ve seen when we discussed it over on Discord. However, I believe the vast majority of nodejs and electron apps out there uses writeFile instead of managing their own file handles and write streams. Obsidian’s fs access is serialized; any attempt to write would have to wait for the previous write to finish, so it should be impossible to call write multiple times without having the promise resolve first.
Another thought: could a 3rd party plugin that modifies the buffer contents possibly be triggering this to happen, e.g. if the timing was “just right” such that Obsidian was executing it’s periodic scheduled save while the user simultaneously triggered a file-altering action such as a Templater script?
This should be safe as long as the plugin uses Obsidian’s file system adapter, or the vault API, instead of directly accessing the through the node.js fs package. As far as I know, most plugins don’t use the fs package because it’s not compatible with mobile.