[Bug] When disk offline and Obsidian saved with error, it will delete the note local and remote(if synced).
Abstract
When Obsidian saves the note with error, it will update local database and mark this file as deleted. If Sync on Editor Save is enabled, it will leads to the deletion of remote storage. (I'm using AliyunOSS, modified some params like the style as Virtual-Hosted and replace HeadBucket to HeadObject method for remote storage status monitoring)
English not good.
Expected behaviour
- If there's an error, the file shouldn't be marked as deleted and let the user to handle the exception.
- If there's an error, the file will disappear on the filelist.
- If this plugin is disabled, Obsidian just not display the file on the file list, but the original file is still there while lost the part not saved.
Actually happened
- File deleted, and remote will delete it.
Reproducing procedure
- Write your Notes.
- Happened (or deliberately make) your disk offline. (Computer not)
- File disappeared from the file list on the left.
- Disk online again.
- Auto or manually synchronize your notes. Both remote and local file disappeared.
Note: I disabled all the trash bin on every partition, so I truly take some of the duty of it. Currently using Windows permission control to disable the deletion permission of all my notes.
Report materials
If the information is not available, do not hesitate to report it as it is. You can also of course omit it if you think this is indeed unnecessary. If it is necessary, I will ask you.
Report from the LiveSync
For more information, please refer to Making the report.
Report from hatch
<!-- paste here -->
Obsidian debug info
Debug info
<!-- paste here -->
Plug-in log
We can see the log by tapping the Document box icon. If you noticed something suspicious, please let me know.
Note: Please enable Verbose Log. For detail, refer to Logging, please.
Plug-in log
- Log:
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->Opening Database...
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->Database is now ready.
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] Initialize and checking database files
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] Checking deleted files
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] Collecting local files on the DB: 25
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] Synchronising...
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] UPDATE DATABASE
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleFileAccessObsidian] xxx <- STORAGE (deleted) 线性代数/正交性和最小二乘法.md
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] UPDATE STORAGE
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleFileAccessObsidian] files: 4
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] SYNC DATABASE AND STORAGE
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] Initialized, NOW TRACKING!
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] UPDATE STORAGE: DONE:1, FAILED:0, LAST:7
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ConfigSync] Scanning customizations...
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] STORAGE <- DB :线性代数/正交性和最小二乘法.md
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ConfigSync] Scanning customizing files.
Everything-e2ca86a8e7926bcc:2025/1/5 19:37:54->[ModuleInitializerFile] UPDATE STORAGE: DONE:1, FAILED:0, LAST:7
SYNC DATABASE AND STORAGE All done: DONE:35, FAILED:0
Network log
Network logs displayed in DevTools will possibly help with connection-related issues. To capture that, please refer to DevTools.
Screenshots
If applicable, please add screenshots to help explain your problem.
Other information, insights and intuition.
Please provide any additional context or information about the problem.
Thank you for opening the issue!
I think that the current design would behave as you explained. However, unfortunately, Self-hosted LiveSync only has information as Obsidian noticed. And, more unfortunately, Obsidian only provides us with information that it has recognised (this means that were indicated as shown on the Explorer). Existence checking says not found even if actually file was.
Toggling Use the trash bin, or performing Pick a file to show history -> Back to this revision may help to resurrect from the situation. However, I am not sure what the essential treatment is, yet now.
I regret to say this but let me leave this issue open. If anyone has any ideas, please let me know.
Since the note re-appears locally in the file system, would it not be possible to make sure the note reappearing takes precedence over the remote sync? A simple way I can imagine this could work by tracking which notes were "deleted" by this client somewhere, and then ignore the sync server trying to delete it again.
A more comprehensive solution: I don't know how this plugin works exactly, but for example if it was using events, a lot of issues like this can be avoided by making sure the source client of a event (like a deletion event) doesn't recieve it again. Because that client should already be up to date. If its somehow in a different state than what the server expects with regards to this event, the client should be considered correct. Because logically, if something new happens, the assumption should be that sync somehow missed something and should believe the client more than the server.
Sorry if what I'm saying doesn't make sense for this, I was looking through the issues for this plugin before deciding to use it and had this idea for solving this issue.