Don't abort when trying to access a deleted file

[PVince81]

In some cases the discovery phase saw files that disappeared at some point before the sync phase reached them. Instead of aborting the whole sync, continue processing.

This was requested here https://github.com/owncloud/core/issues/26302

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ckamm]

Files that return 404 on download should be gracefully skipped already, see 28d6d0dc1eb3b378e17df78021de8b5969352947 #2227, included since 2.0.0. I'll read the original ticket.

[tomas4]

Probably related (in 2022, ownCloud client version 2.5.1 on the Sparky Linux), the server is a public service of Cesnet academic network) : I have put one 10+ GB file into a synced directory on one client (client1), it was uploaded to the server and started to be downloaded on two other clients (client2, client3). Both client2 and client3 are on the same wifi with relatively slow connection. The estimated time of completion was initially around 10 hours, so I decided to do it a different way and deleted the file on client1. Although after a while I can see on client2 and client3 in the GUI they know the file was deleted on client1 and the file is not showing on the server via web interface, both clients continue to download the file for hours. I even do not see any way to abort that manually permanently - after I pause the syncing and resume it, even after I exit the client app on client2 and client3 and start it again, the download resumes. I consider that to be a severe design flaw...

[TheOneRing]

Why are you using a 4years + old client?

[jnweiger]

Do you see the same behaviour with 2.10.1 clients? I don't have Sparky Linux here, but I'd assume, the appimage should run just fine. https://download.owncloud.com/desktop/ownCloud/stable/2.10.1.7389/linux-appimage/ownCloud-2.10.1.7389.AppImage

But then, I am wondering, if that is more of a server issue, than a client issue. This might be what happened:

1. client 1 uploads the file to the server
2. clients 2 and 3 pick up the file and start downloading.
3. while that download is in progress, the file is deleted.
4. A delete normally does not delete anything, the file just moved on the server into the user's trashbin.
5. the download process refers to the file by file-id, and can continue (even after restart), as that file-id still exists in the trashbin

Just a conjecture for tonight...