Client folder deletion after server groupfolders:scan

[depasquale]

Dear all, after being using Nextcloud with Group Folders since several years I found a possible bug to be potentially investigated.
My use case is arising from a disaster recovery scenario.

First let me say I have no damages because of backups, but let me show you a possible dangerous behaviour I see with Group Folders commands and application.

My VM data volume has gone because a damage on the disk that was not recoverable from Unix (out of the scope of interest). So I tried to mount a new volume and restoring on serverside the folders considering the database was correctly working and all the clients (Windows Nextcloud Apps) were updated with virtual files enabled.

I created the "/data/__groupfolder/1" folder with the physical copy of the files I recovered from the broken data volume. They were just few folders recovered and I was hoping the sync process will restore the files from the edge computers to the central storage.

Disabling maintenance mode the windows client marked as green the group folder. The local files at edge were correctly available and with the possibility to open them. On the server side the web interface were showing the proper file list for all folders.
The files at the edge (client side) were not synchronized to the server side (obviously the local database does not see any updates). And I know that in a unix based system just "touching" the files would causing the new sync.

But I tried to use occ groupfolders:scan --all to try to force the server to clean its database informations and than integrate the server side files with the clients files considering that the files on the client (at this point of the scenario) can be considered as "new files".

Instead, as soon as the command completes the files at the edge (on the local windows computer) were completely deleted without any trace in the trashbin neither in the nextcloud trashbin, nor in the local windows trashbin.

I think this behaviour (deleting client files without any warning or error or any "are you super sure you want to throw away your data") is really dangerous.

In order to test this behaviour you can:

1. create a group folder and sync with a local computer via Nextcloud Desktop App
2. insert some folder and files to sync with the cloud
3. access the cloud and remove from the file system some files or user uploaded directory
4. invoke groupfolders:scan --all
5. checking the local computer files and folder

My suggestion, if developers agree, is to preserve the files at edge with a process similar to what we are used to see with conflicting files. Or at least having some possibility to choose when scanning if missing files on the server (but present in the database) shall be seen as a deletion or a conflict to be resolved at client side.

It would be very beneficial to have the possibility to leave to the user the possibility to choose which files to upload/restore after, for example, the IT disaster recovery process has been completed considering that for its nature Nextcloud can be used as a multinode distributed storage and for this reason used by many organization or individuals (like me) to improve the resilience of the file storage on multiple nodes.

Hope this fact can be verified and then improved in the next versions.
Regards,
Davide