Deleted files after restoring backup

[vguna]

Hi.

Yesterday, I had to restore my whole server from a backup. One days work was gone. After the backup was restored, the desktop sync client started to delete the local files which were created and synced during that day. I had expected, that the local "new files" would simply by be synced to the server as new. But they have been deleted and I have no chance to restore them.

So I would like to have either an general option that a user of the desktop client has to confirm a delete in general, or that such files should be simply interpreted as new. I don't know if there's a change to identify that the server has taken the travel back in time and handle it accordingly on the clients.

[tflidd]

There is already an issue about this topic: #2325

Because the behaviour is different between OC versions, you should tell the developers the version you are using. The issue template helps you to gather all important information:
https://raw.githubusercontent.com/owncloud/client/master/issue_template.md

[vguna]

Ah ok. Thanks for the info!

Here are the requested infos:

Expected behaviour

After the rollback, the client should either:

• ask the user if the delete should be performed (maybe a good option in general)
• consider existing local files as new or newer than the ones on the server
• delete the files locally, but put them in the recycled bin or server trash bin

Actual behaviour

The desktop client simply deletes the files without being able to restore the deleted files afterwards.

Steps to reproduce

• Have a desktop client with synced files
• Add a new file and let it sync
• Rollback the server by installing a backup that was created before the new file was added (virtual server image including DB/filesystem etc.)
• Verify that the new file is deleted after the restore is complete and the desktop client finished syncing

Server configuration

Operating system: Ubuntu 14.04.2 LTS
Web server: Apache 2.4
Database: postgresql 9.3
PHP version: 5.5.9
ownCloud version: Community 8.1.4
Storage backend: local fileystem

Client configuration

Client version:.2.0.1
Operating system: Windows 7 64bit
OS language: German
Installation path of client: D:\something

Logs

Sorry, no logs available anymore

[dragotin]

Two ideas how we could try to detect this condition:

• The inode of the root sync folder. If that has changed, it's fishy
• File modification times: Usually the times only become later. However, in case of backup restore, the time can change to become "earlier". We could detect that and ask the user if that happens.

@ogoffart makes sense?

[ogoffart]

The inode of the root sync folder. If that has changed, it's fishy

Sure, but it won't help in that case since the inode of the root sync folder does not change. (and we currently don't store it, and if that's the case, must likely the etags of all the other files will also change and we already detect this case)

File modification times: Usually the times only become later. However, in case of backup restore, the time can change to become "earlier". We could detect that and ask the user if that happens.

That is a good point.
We could detect that and if the modification time of all the modified files on the server is in the past, we show a confirmation.
Great idea.

[ogoffart]

Duplicate of #2325