Fix sync errors when trying to delete video component of live photos

[claucambra]

Live photos uploaded to the server are composed of an image file (usually a .jpeg or a .heic) and a video file (a .mov file), which get presented to the user via the iOS and Web UIs as a single "live photo", like in the Apple Photos applications

To maintain this representation the server treats these image/video pairs as inseparable -- the video cannot be deleted by itself, only a delete of the image will lead to the deletion of the video. This means we cannot issue deletes for the videos, as the server will reject this and we will end up showered in sync errors.

This PR therefore changes the local discovery behaviour to not propagate the local deletion of live photo mov files to the server, and to instead simply re-download the file if it has been deleted

[claucambra]

/backport to stable-3.14

[klada]

@claucambra When copying a folder containing "Live Photos" to a different location, what happens to the isLivePhoto property of the respective files?

[claucambra]

@claucambra When copying a folder containing "Live Photos" to a different location, what happens to the isLivePhoto property of the respective files?

From the client perspective, we propagate the copy to the server and then pull down whatever state these files are in post copy remotely. We don't manually mark these new files as live photos (at least, not at the moment)

[klada]

@claucambra When copying a folder containing "Live Photos" to a different location, what happens to the isLivePhoto property of the respective files?

From the client perspective, we propagate the copy to the server and then pull down whatever state these files are in post copy remotely. We don't manually mark these new files as live photos (at least, not at the moment)

I have just tested 3.14.3 on Mac OS and the sync client does not use COPY requests for copying subtrees (CMD+C on a folder, CMD+V in a different place). Instead, subtrees are created as completely new directory structures through multiple MKCOL requests for the actual folders and re-uploads of the contents through multiple bulk POST requests.

That's why I am a little in doubt if the content's isLivePhoto flags will be retained in this situation. Shouldn't these bulk-POST-ed files look like completely new files to the server with the current architecture? Or am I missing something here?

[nextcloud-desktop-bot]

AppImage file: nextcloud-PR-7435-3b5222d457d43845039c0d942a9ff0895399ecc6-x86_64.AppImage

To test this change/fix you can simply download above AppImage file and test it.

Please make sure to quit your existing Nextcloud app and backup your data.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud