“file uri scheme”

@lateef Please file a code-level support request including your Team ID for assistance.

In the callback, I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store, it is simple enough for me to just ignore the error and return COPYFILE_SKIP, but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback, if I read errno, it is 0. When copyfile returns, it returns -1 after I return COPYFILE_QUIT (and errno is 0), so I don't know what the error is or the appropriate way to handle it. FYI, the code to copyfile is actually open-source, so you can fairly easily find all of the places where your callback would have been called by looking for COPYFILE_ERR in the source. However: For .DS_Store, just skipping seems reasonable, but when copying a folder, it may be appropriate to get the true failure reason. ...I'd ignore all .DS_Store errors and, potentially, just skip copying them all together. The system will generate the file anytime it needs/wants to, and it's very likely that it won't consider th

This was always my understanding of xattrs. Yes, and I think part of what's helpful here is to not think of the resource fork as just another xattr. Its age makes it a special case. Interesting. I was using the xattr API. So just skipping the resource fork during copyfile, then running copyfile again over the src and destination (with .namedfork/rsrc convention) seems to work on my dummy test file. Is that expected to be a reliable workaround? So, the reason I keep asking the what's actually happening question is that IF this is in fact a compressed file, then just copying the resource fork won't actually work. There's an additional UF_COMPRESSED file flag that needs to be set, which then marks the file as compressed so that the system knows to retrieve and decompress the file contents when the file itself is opened. If you read through the previous threads, you can see that this flag is what ends up hiding the presence of the resource fork from the rest o

Thanks for the post, I would recommend to submit a bug against TestFlight for this. Don't forget to include the screenshots and steps to reproduce it. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

Thanks for the post, can you provide me the correct URL for the AASA file? the links above are not correct. If you prefer provide me this information in private. Go ahead and submit a code-level support request so we can discuss this further privately. When you create the request, indicate that you were referred by me at Apple and make sure to include a link to this thread. Thanks Albert Pascual
  Worldwide Developer Relations.

Thanks for doing the thorough test, and sharing your test result, which is very well-written. The details unveiled in the result is definitely very helpful. Just to confirm that, other than an active HKWorkoutSession, there is no API that can trigger high-frequency heart rate sampling. Also, thanks for filing the feedback report. Best, —— Ziqiao Chen  Worldwide Developer Relations.

@ScottyBlades Thanks for the post and sorry for the delay. Please check your server settings as your server does not accept a user agent and that's required for AASA files: curl -I -A Albert-Bot/1.0 https://akin-server-side.onrender.com/.well-known/apple-app-site-association HTTP/2 200 date: Wed, 18 Mar 2026 17:08:53 GMT content-type: application/json; charset=utf-8 cf-ray: 9de5d789480c7e25-SJC rndr-id: e8574d04-55fd-4b1d vary: Accept-Encoding x-render-origin-server: Render cf-cache-status: DYNAMIC server: cloudflare alt-svc: h3=:443; ma=86400 Everything explained in this well written Tech Note: TN3155: Debugging universal links | Apple Developer Documentation#Host-and-verify-your-AASA Albert Pascual
  Worldwide Developer Relations.

Hello - In order to resubmit your three IAP subscription products, the status of each needs to change from Developer Action Needed to Ready to Submit. We recommend editing each of them, in order to save an update (e.g.: add a note to the Review Notes section like [Date] Updating IAP to resubmit with new binary of Version 1.x of [App Name]. Once the status of the IAPs has been successfully updated, proceed to submit a new version of the app - and attach the three IAPs for review as documented here under Submit an In-App Purchase of the first time. If you are still unable to resubmit the IAPs with a new app build, please file a detailed ticket (including screenshots and/or video) via Feedback Assistant, and reply back to this thread with that ticket number - and we will follow-up. Thank you.

Thank you for your post and providing this information. I recommend using the direct line you have with Feedback Assistant to upload those files to the team working on your bug. Directly communicating with the appropriate team is always the most efficient approach. If you are unable to do so, I can assist you with the upload. Please let me know how you would like to proceed. Albert Pascual
  Worldwide Developer Relations.

Thanks to all for your post about TestFlight. I'm not aware of any issues in TestFlight at this time, but it seems like many of you are getting into an issue. Can you please one of you submit a bug against TestFlight with the sysdiagnose and all the error messages you are getting so a team can investigate? Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Thanks, Albert Pascual
  Worldwide Developer Relations.

Just read your reply again more carefully as it is not the end of the day and I'm not tired :) . As the thread up above shows, the primary way to bypass the issue copyfile is having is to use the ..namedfork/rsrc convention, Interesting. I was using xattr API. So just skipping the resource fork during copyfile, then running copyfile again over the src and destination (with .namedfork/rsrc convention) seems to work on my dummy test file. Is that expected to be a reliable workaround? I guess if this actually works reliably I wouldn't have to restart copy from scratch or suppress deprecated API warnings. Or maybe there good reason to start the copy from scratch with the Carbon file manager?

Thank you for the thread attached in your response. The issue faced above internal to the Salesforce B2C Commerce Business manager configuration. We are working for a US based site where 3DS is optional for merchants. Hence we did not enable it in our Business Manager portal. Later, we found that 3DS is mandatory for Apple Pay to work. Below is the documentation shared by Salesforce with us. https://developer.apple.com/documentation/applepayontheweb/applepaypaymentrequest/merchantcapabilities This information is neither logged in the browser console nor in the server side logs as there was no authorization event being triggered from applepay.js file hosted on Salesforce B2C Commerce instance. This has become a grey area for us to reach out both Apple and Salesforce. After enabling 3DS, we are seeing the authorization event triggered. Hope this answer helps for others who face similar issue on Apple Pay on Salesforce B2C Commerce aka Salesforce Commerce Cloud (SFCC) formerly known as Demandware.

[quote='880351022, KayleeSC, /thread/791352?answerId=880351022#880351022, /profile/KayleeSC'] Omg it was the / at the end. [/quote] Well, blat! [quote='880351022, KayleeSC, /thread/791352?answerId=880351022#880351022, /profile/KayleeSC'] I’m gonna send this to the testers and see if that’s it. [/quote] Cool. If that does turn out to be the problem, I’d appreciate you filing a bug about it. The system should either tolerate this or vend a more helpful error. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com