Delete notebook in Orgzly when file has been deleted in repository

[iexos]

Every time i delete an org file, it is recreated when opening Orgzly. Instead, I would like to be able to delete a file on another device and have it removed from Orgzly as well.

This is especially important when using Syncthing underneath the file sync, as it can create sync-conflict files which are better resolved (and then deleted) with a proper text editor. Now I have to delete it from Orgzly, and it would make it impossible to use two syncing Orgzly instances.

[naught101]

I'm also finding this annoying in Orgzly with syncthing.

It might be good to have an alert when this happens:

"notebook was deleted from repository. Delete from Orgzly too?" Yes/no, and "remember my decision"

Plus something in the settings to reset the "remember my decision" thing. I'm perfectly happy for it to always delete, but it might cause data loss in some cases.

Another option that would help with the syncthing case (and possibly also other cases) would be to have an ignore pattern for org filetypes, e.g. ignore *.syncthing-conflict-*.

[appetrosyan]

I have an idea for an easy fix. Check if the notebook was ever synced to or from the cloud. If it's present locally, but not on the cloud, ask whether to reupload the local version to the cloud or to remove it.

[DrAzraelTod]

Got 4-5 devices that sync files edited by Orgzly (and some text editors)

It's nearly impossible to delete a org-file - like ever

Whenever I'd want to do that, I'll have to delete the file on each device BEFORE one of the other devices synced it's changes back onto my server and re-creates the file.

Alternative Implementation: when a notebook is synced and the file doesn't exist, at least ASK if the file should be re-created.

[nevenz]

Whenever I'd want to do that, I'll have to delete the file on each device BEFORE one of the other devices synced it's changes back onto my server and re-creates the file.

I'm looking into some changes for repos and syncing (for new repo types) and will be having this in mind.

[halvorlu]

Any progress on this issue? If not, I might try implementing a solution. My best suggestion is to ask the user whether to delete the file on device, or sync it, as suggested by @DrAzraelTod and @appetrosyan.

[nevenz]

Any progress on this issue?

Not that I know of.

My best suggestion is to ask the user whether to delete the file on device, or sync it, as suggested by @DrAzraelTod and @appetrosyan.

The problem with asking is that sync is done in the background and can also be started automatically. So user might not be in the app.

But perhaps it could be just marked as deleted and not synced after that. It could be flagged in notebooks list and user could delete it manually later.

Though I wonder if this is even worth it (it does feel kinda hackish) and how risky is to simply delete the notebook.

[halvorlu]

My thought was to treat deleted files in the same way as files that have been changed both in the app and in the cloud, i.e. with a Force Load/Save option. With this approach, you would get the option to Force Load/Save whenever a file is deleted in the cloud, or a new notebook is created in the app. These two cases may be slightly tricky to distinguish from each other(?), so they could be treated equally.

This does not feel hackish to me, the only disadvantage is the need to explicitly confirm that a new notebook created in the app should be synced to the cloud. This could eventually be fixed by a flag that indicates whether the notebook ever existed in the cloud. (Or possibly by using already existing variables?)

[nevenz]

This could eventually be fixed by a flag that indicates whether the notebook ever existed in the cloud. (Or possibly by using already existing variables?)

Yes, Book has this information.

[tbc]

Although inconvenient, some may find this workaround helpful.

1. Clear local database in app
2. Re-connect repository
3. Sync

[philip-bl]

Does this problem happen when syncing via dropbox?

[codygman]

This could be easily avoided if orgzly had an exclude file feature so that *.syncthing-conflict-* notebooks are never created. Does this exist?

Ignoring on syncthing is bad because you could lose data. It's good to sync your conflict files, the problem is we need orgzly to ignore them I think.

[philip-bl]

@codygman It seems to me the problem doesn't have anything to do with syncthing. If you used another program to sync your directory containing org files, the problem would still be there.

[codygman]

@philip-bl I didn't say the problem has anything to do with syncthing. It's because orgzly has a database as the source of truth rather than the filesystem synced by syncthing or any other file syncing tool.

You could get around the problem by making sure *.syncthing-conflict-* files never get into the orgzly database with orgzly provided ignore functionality.

[philip-bl]

@codygman I don't see what *.syncthing-conflict-* files have to do with anything. Orgzly has this problem even without syncthing.

• Orgzly is configured to sync with foo directory
• I have foo/bar.org file - it can be seen both in file system and in orgzly
• I delete foo/bar.org from the file system
• I press sync in orgzly
• Orgzly recreates foo/bar.org in the file system, which is not what I want

[codygman]

@philip-bl Ah, okay. I've only used orgzly with syncthing so I didn't know that. I almost never delete my org files either, so just a way to ignore any conflicts so orgzly doesn't keep them alive would have sufficed for avoiding "zombie" files.

[alphapapa]

I understand the difficulty of implementing this feature in a way that does not make it easy to accidentally delete notebooks. I certainly prefer a cautious approach. And deleting a notebook is something I do rarely, so it's not a tremendous hassle to clear the database and re-sync after deleting a notebook on my PC.

Until this feature is implemented, this limitation and workaround should be documented in the manual. I spent several minutes repeatedly, carefully looking through the options and menus to try to find a "Delete notebook" button, and then searched the "Getting Started" notebook. I finally had to come here, to the GitHub repo, to find information about deleting notebooks.

[x-ji]

One problem with clearing the database and then re-syncing is that all your custom searches would be lost as well, which is really inconvenient.

Before a proper fix is implemented, I think at least the app could offer an option to preserve the custom searches when clearing the local DB, which should only delete the files, but not the searches.

[debnath-d]

Any update on this issue? Last comment on this thread was almost a year ago!

[codygman]

One problem with clearing the database and then re-syncing is that all your custom searches would be lost as well, which is really inconvenient.

Yeah, it kept me from actually using saved searches since I'd have to just delete them anyway or fix a lot of "conflicts". Which is sad, because that's one of the most valuable things in orgzly when I think about it.

[aaaawwWWWwwwwWWW]

In my case I had to remove the repository and clear the database (settings > app > clear database > ok), and re-add repo because of this.

[debnath-d]

Any update on this issue? Last comment on this thread was almost a year ago!

More than a year since my last comment! This is the only thing stopping me from using orgzly.

[billwanjohi]

This is especially important when using Syncthing underneath the file sync, as it can create sync-conflict files which are better resolved (and then deleted) with a proper text editor.

My rather tedious workflow for these conflicts is:

1. ediff the conflicting files in desktop emacs, making their contents identical
2. trigger a pull on Android
3. delete the duplicate note in Orgzly, checking Delete linked remote notebook

---

I think at least the app could offer an option to preserve the custom searches when clearing the local DB, which should only delete the files, but not the searches.

Agreed that this can create some nasty surprises, but you should know that you can manually export¹ your searches to a local file and then re-import them after a database purge.

Footnotes

1. From the dropdown menu in the Searches index. ↩

[karlicoss]

While it doesn't exactly solve it, as a workaround, I empty the file and set the org title to DELETE ME, that way I can just unlink the file from orgzly the next time I spot it in the notebook list
(still won't help with multiple orgzly apps on different phones though)

[xeruf]

gash, now I know why all the sync-conflicts keep reappearing...
and you can't even batch-delete notebooks it seems?

[tbc]

I started using Syncthing. I have renewed interest in seeing this bug get fixed.

[Itrekr]

Can this please please please be fixed? I have a workflow in which I regularly delete notes which is impossible to maintain with this. Every time I delete a bunch of notes they just come back.

[debnath-d]

I've moved to logseq and advise others to do so

[Itrekr]

I've moved to logseq and advise others to do so

The primary reason I use orgzly is because I need the integration with tasks. Does that work on logseq? Also: are there any synchronization options available there? If it requires external synchronization it's very hard to make it work well with nextcloud.

[Itrekr]

I created a bit of a workaround that is acceptable to me for the time being. I am posting it here in case someone might find it useful.

I have created a custom function which goes through all of my journal files one by one and gives me the option to either keep [k] or delete [d] the file. In case I choose delete, a task gets added to the bottom of the file with the 'delete'-tag in order for Orgzly to be able to find the files with a filter.
I added a filter in Orgzly which only shows things with the 'delete'-tag so that I can double check which (and how many) files I should manually delete. If I do this immediately after I've done the marking of my note files they should all be at the top of the list (if sorted by modification date). That way it's just a matter of selecting them one by one and removing the remote notebooks.

(defun org-roam-dailies-clean ()
  "Keep or tag note files for deletion."
  (interactive)
  (let ((daily-directory (expand-file-name "NameOfJournalDirectory" "/path/to/this/directory/"))
        current-file)
    (dolist (file (directory-files daily-directory t "\\.org$"))
      (setq current-file file)
      (find-file current-file)
      (let ((keep-or-delete (read-char-choice "Want to [k]eep or mark for [d]eletion? " '(?k ?d))))
        (cond ((eq keep-or-delete ?k)
               (message "Keeping %s" current-file))
              ((eq keep-or-delete ?d)
               (goto-char (point-max))
               (insert (format "\n* TODO %s :delete:" (file-name-nondirectory current-file)))
               (save-buffer)
               (message "Marked %s for deletion" current-file))
              (t (message "Invalid option"))))
      (kill-buffer (get-file-buffer current-file)))))
(map! :leader
      :prefix "n"
      :desc "Keep or mark note files for deletion" "rk" #'org-roam-dailies-clean)

This method could be billion times easier if it would be possible to:

1. Use filters for file tags instead of note tags. This way entire files can be tagged and removes the necessity for adding a special task just so Orgzly can filter for it.
2. Bulk select notes for (remote) deletion.
3. (Remote) delete selected note files from a filtered view / delete entire corresponding note files of a specific task
4. Just have a working two-way sync system in general