Implementing a 'trash can' feature on iOS - thoughts?

I’d like to have your views on a feature I am considering to implement in the iOS app, and its possible implementations.

Background: Because the iOS app offers selective synchronization, it must also deal with files that are ‘new’ (i.e. appeared in the folder locally but are not ‘selected’ i.e. ignored). The app does this by presenting a screen asking the user to keep (unignore) or remove the file. A similar function is present for subdirectories. When a user unselects a file, the app deletes the local file (in the case of unselecting a folder, the app currently doesn’t delete the folder, but it should). While convenient it is also possibly a source of mistakes where files may inadvertently get lost.

To this end I would like there to be an option in the app to move any file that is deleted to the system Trash Can first. This is accomplished (on iOS) by making a specific call into the ‘NSFileManager’ API.

My current idea is to implement a custom filesystem type that changes the behaviour of Remove/RemoveAll to call this function instead (it’d have to deal with duplicates and whatnot of course). This would (after filtering removals to .stignore/.stfolder* and .syncthing*) also function as a sort of bare bones ‘versioning’ feature.

As for implementing the custom filesystem from outside, I’d need to add a method to the ‘Internals’ type where I can register my custom filesystem type (and then refer to that type from the config for folders that have this trash can feature enabled). Mobius seems to have done something similar in a bit different way (see First iteration of photo sync · MobiusSync/syncthing@a642703 · GitHub) and is using it for photo synchronization (presenting a virtual file system of the system photo album I assume).

Alternatively I might be able to just use the existing versioning feature, but of course that only catches files that are removed remotely. Perhaps there is a way to call into that and tell it to also archive some arbitrary other local file (before the app will delete it).

@calmh and others, would you have any thoughts on this?

Signed on to this forum for the first time in a long time. Just learned that there is an iOS app, and that we’re losing the Android app. Weird day.

Sounds like a cool feature idea though. Thank you for your development work on this project.

If you implement this change in Syncthing’s file system abstraction layer, it still won’t be able to version locally deleted files. So what’s the point of adding a separate mechanism then, which is already covered by the versioning configuration?