Orgzly-android: Delete notebook in orgzly when deleted as file (auto-syncing)

[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.

[keyb0ardninja]

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.