Sync the .trash folder via Obsidian Sync

Reason for Feature Request

My vault’s .trash folder does not appear to synchronize across multiple devices when using Obsidian Sync:

A file that shows up in the .trash folder of one PC…

  • Does not show up in the .trash folder of another PC (and vice versa)
  • I don’t even see a .trash folder in the iOS mobile app

This is dangerous because if you purposely or accidentally delete a file on one computer, and later are on a different computer and realize you need to recover that file, you will be confused because you won’t see it in your .trash folder. This would either lead you to believe that you have completely lost the file, or require you to realize you need to individually search the .trash folder of every computer you own, which may be impossible if the computers are at different locations.

I don’t even see the existence of a .trash folder in my iOS mobile app either, which ideally it should have for the same reasons above.

This seems counterintuitive since Obsidian Sync seems to be intended to do sync everything and is supposed to have the ability to restore deleted files.

Alternatively, if the Settings->Sync->Deleted Files feature successfully was able to bring back deleted files regardless of which computer/device I’m on, that would be fine instead of the actual .trash folder being synced.

Steps to reproduce

  1. On two separate PCs (Windows 10), open the same vault that is connected via Obsidian Sync
  2. Ensure that on both of these PCs, your Obsidian’s settings are set such that the “Files & Links” tab has “Deleted files” set to: Move to Obsidian trash (.trash folder)
  3. On the first PC, create a new note, with any title (e.g. “test note”)
  4. On the second PC, verify that you can see the note you created (meaning Obsidian Sync is synchronizing correctly).
  5. On the first PC, right click->delete the file
  6. On the first PC, using the Windows File Explorer, go to the location of the .trash folder in your vault, and confirm you see the “test note.md” in the folder.
  7. On the second PC, confirm that within the Obsidian app, the “test note” has disappeared (meaning Obsidian Sync is synchronizing correctly).
  8. On the second PC, using the Windows File Explorer, go to the location of the .trash folder of your Obsidian vault. You will not see the file you deleted

Ideal result (feature request)

You should see the file you deleted in the .trash folder of both PCs (and ideally your iOS folder as well)

Actual result

The file you deleted only shows up in the .trash folder of the PC you used to delete the file.

3 Likes

This is not a bug. It’s not supposed to. Trash, whether you use .trash or your os is not synced.

Thank you @WhiteNoise for the clarification. If you believe this is better suited for a Feature Request, feel free to help me move it over.

However, the current behavior does seem odd and counterintuitive, possibly resulting in the situations I mentioned above where a user is confused at not being able to recover a file.

So for that reason, I would like to request that .trash be synced, as it falls within the vault folder, which is within the Obsidian Sync directory.

On a related note, when I go to Settings->Sync->Deleted Files, I am able to see the deleted note in the list (regardless of which computer I’m on), but if I try to click it and then click “Restore this version”, I simply get a message that says “This version is already the latest version” and I do not see it moved back into my vault (non .trash) folder.

That also seems counterintuitive, since it appears as if Obsidian Sync is offering me the ability to restore my deleted file back into my vault regardless of where I deleted it from (which is a useful ability).

(and as a side note - how is one to restore an accidentally deleted file on iOS if there isn’t access to a .trash folder?)

1 Like

I’ve moved it over to Feature Requests and changed the title to be more request-sounding.

1 Like

Thanks so much, I appreciate it! I re-arranged the text in the description so that it is more conducive to jumping straight to the feature request instead of reproducing the steps first (since I originally thought it might be a bug).