I have a FileProvider based MacOS application where i am trying to download a large folder. The folder has mix of small and large files. Large files are around ~1.5 GB size. I was able to download few files however i have observed that for large file downloads the URLSession times out and download fails. There is no explicit time out set by my application so it is 1 min default. I disabled QUIC by setting enable_quic to false from /Library/Preferences/com.apple.networkd.plist and found that the download worked for the same folder which was not working earlier. I suspect something is failing in network layer. Also i checked the server logs in Kibana where i didn't find the entries around those files that were failed to download which means the requests didn't even reach to server and failed before that. I already tried increasing the time out for URLSession which didn't work. I want to disable QUIC only for my application not for whole system. URLSessions belongs to my application should have QUIC disabled. So i am checking if it is even feasible to disable QUIC for application.

Thank you for your reply. Yes, we are receiving this error from URLSession. in our fetchContents implementation, we are downloading a file using URLSession's api downloadTaskWithRequest. if i am not wrong you are suggesting to move from data to download task. The api we are using is a variant of download task and we are already using that which directly saves to the file. is this happening due to multiple instances of URLSessions being spawned and used across the app? While debugging, i noticed ~40 instances of URLSession are created during download of large folder(having sub-directories and large files). has there been any changes in MacOS recently which lower down the limit on the number of active URLSessions?

I also tried reproducing the issue by deliberately increasing the pressure on RAM in an assumption that this issue occurs when the system ran out of RAM but could not reproduce the issue in this scenario.

Hey, I am also facing the similar issue. I am using one raw binary and have embedded the info.plist in it. The plist is properly embedded, i have confirmed it using launchctl plist binary and it contains both these keys. However the version in Crash report still shows as ???. Any clue? Thanks, Aparna Joshi

No. It doesn't appear in the Finder if i do it manually. I have to go to mount path to see the mounted share.