[fix/recursive-fp-copy] Fix recursive copy in File Provider

[felix-schwarz]

Description

This PR fixes an issue where trying to copy and paste a whole folder hierarchy into the File Provider could render inconsistent and incomplete results.

Related Issue

https://kiteworks.atlassian.net/browse/SE-1082
owncloud/ios-sdk#162

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[jesmrec]

Since this affect a complete feature of the app, a sanity test was done to check beyond the reported defect

[WIP]

1. Copy from device to oC

• Copy 1 file (the most basic case) ✅
• Copy 10 files ✅ . Sometimes the error of "no permission"
• Copy a folder with 20 files but no folders inside ✅ (1 level of depth)
• Copy a folder with 20 files and a folder inside that contains 20 files (2 levels of depth) ✅
• Copy a folder with 10 folders inside that contain 20 files each (2 levels of depth) ✅
• Copy a folder with 10 files and folders inside. Every folder contains other 10 files and and 10 folder that contain 10 files (3 levels of depth) ✅
• Copy all above together ⬆️

2. Copy from oC to oC

[jesmrec]

(1)

That's probably kind of side-effect, not about this fix itself.

I use to get an error (crash?) in the fp when copying from oC account as origin. My guess is that the error/crash happens when the file has to download first (required to upload the file to the target account via fp), because that step is skipped in the "local device → oC account" scenario.

Video and logs caught:

ScreenRecording_07-10-2026.13-17-08_1.MP4

ownCloud_10_Jul_2026_at_13_15_29.log.txt

(i found no crash log inside, so, i will let you better explore it)

Unfortunately, this is not deterministic (idk what it depends on), but i can frequently reproduce it.

Any input about this @felix-schwarz? thanks in advance

[felix-schwarz]

@jesmrec Thanks for (1). I've since been able to reproduce it and found the following:

• at least on iOS 26 (others not tested) the system makes a call to the optional (and therefore unimplemented) property documentSize, which leads to a crash. I added an implementation to fix / work around this. That doesn't seem to be what you saw, however.

• the error you saw comes from the iOS NSURLSession:

Task <24375D68-F9FE-4D14-A3B7-DD93FEDBFAFE>.<13> finished with error [-996] Error Domain=NSURLErrorDomain Code=-996 "Kommunikation mit Hintergrundübertragungsdienst nicht möglich." UserInfo={_NSURLErrorRelatedURLSessionTaskErrorKey=(
    "BackgroundDownloadTask <24375D68-F9FE-4D14-A3B7-DD93FEDBFAFE>.<13>"
), NSLocalizedDescription=Kommunikation mit Hintergrundübertragungsdienst nicht möglich., _NSURLErrorFailingURLSessionTaskErrorKey=BackgroundDownloadTask <24375D68-F9FE-4D14-A3B7-DD93FEDBFAFE>.<13>}

It only occurs when using background NSURLSessions. Looking for more information on this error code, I stumbled upon cryptomator/ios#351 which hints at changes on how Files.app uses File Providers - in essence running each "domain" (account) in its own process, leading to conflicts around background NSURLSessions. I'll need to look more into this, but think it is out of scope of this PR and better suited for its own issue / PR. I'll file one.

Copying within the same account of folders generally appears to work just fine - regardless of whether the files in the folders already have a local copy or not.

[jesmrec]

at least on iOS 26 (others not tested) the system makes a call to the optional (and therefore unimplemented) property documentSize, which leads to a crash. I added an implementation to fix / work around this. That doesn't seem to be what you saw, however.

that's a technical one, i was not able to reproduce. Any clue @felix-schwarz ?

About (1), fix has been deferred to #1568. So, i will test the remaining stuff there.