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.