“file uri scheme”

Hi and thank you for confirmation for this issue. I've filed a bug on this already (r.172771068), but I'd appreciate your filing your own bug and posting the bug number back here. I have created a Feedback Assistant for this: https://feedbackassistant.apple.com/feedback/22266931 Also created a Code-Level Support case, with the same title as with Feedback Assistant but it seems to be private. Please inform if I may have missed anything. Once again, thank you for support.

Have you filed a bug on this and, if so, what is the bug number? Not yet, but I do have another thread where I describe the same problem in regards to .DS_Store: https://developer.apple.com/forums/thread/819041 I will post the bug number (most likely there) when I carve out a little time for it. Currently if copyfile fails and errno is not set my code falls back to a kind of 'Unknown Error' which I hate but if the user is counting on my app to perform the copy it's kind of a gamble if the operation doesn't succeed to just hope not critical data was lost. A big part of this is that xattrs aren't actually safe“— the system doesn't have a documented system for defining how they should be handled, and app/copy engine/file format support for them is inconsistent, so storing critical data in them can end up being a good way to lose critical data. Importantly, that kind of data loss isn't really a bug in the same way other kinds of data loss would be. The general point of xattrs is to allow the att

I'm experiencing this issue. Copy file works locally for these files but fails when coming from a NAS. So, the first question here is what these files are and how they got onto that NAS. More specifically, there are basically only three reasons a file would have a resource fork today: It's really, really old. Apps were discouraged from using the resource fork from the very first release of macOS X and the Resource Manager (the only API that allowed access to it) was deprecated in macOS 10.8. Files that are intentionally using it should not be common. It's actually a compressed file. I described that case above, but the key point is that compressed files should never be leaking off of our volumes. Something else (weird) is going on which I'd love to understand. The most likely explanation here is #2, however, making that happen means something didn't work properly, which is what you should identify and correct. Works from Finder in both cases, as p

Since you're seeing this often, please open a bug report with some URLs to example builds so we can investigate. Make sure to include the details about the URL and the DNS errors. once you have that FB number on file, please post it here for the record. — Ed Ford,  DTS Engineer

Please file a Feedback report using Feedback Assistant, then post the ID here.

I have multiple Apple Pay Merchant IDs for different locations, each requiring its own domain association file. This forces me to verify each Merchant ID on a separate subdomain. The problem: the Apple Pay session must be initiated from the verified subdomain. It works on 10171.example.com but fails on www.example.com. I want to keep a single top-level checkout domain without redirecting users to subdomains. Is there any supported way to do this, or is top-level navigation to the verified domain always required for multi-Merchant ID setups?

I would like to note that both the documentation you have linked and our developer portal for enabling this entitlement both mention this API is macOS only. The documentation and portal are both wrong. I'm working on getting the portal fixed (r.162380702) and I'll try and let you know once that's done. On the documentation side, I'd appreciate you filing your own bug on that issue and then posting the bug number back here once it's filed. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I filed FB22260532 Perfect, thank you! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I’m going to consult with a colleague about this, but I suspect that this is ultimately going to end up being a bug report. Yes. If you haven't already, please file a bug on this and the post the number back here. Once I've got the bug number, I'll follow up with the engineering team to see if there are any other options here. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Please file a feedback report via Feedback Assistant and share the feedback number here once submitted. Include the OS, Xcode versions and sample code you're able to reproduce the issue on.

Thank you for providing the code. I modify a bit to be able to build in our DUT FYI, my original code has some logic flaws that I eventually sorted out with a bit more testing and experimentation. The underlying math here is that the BCT binning test is equivalent to the combined probability of rolling 10 3-sided dice and having either or both of these occur: The same number appear on 4 or more dice -> ~31% At least one number not appearing at all ->21% ...and the combined probability of those two events works out to about ~40%. I suspect/assume that you're having test runs that OCCASIONALLY succeed, but the inherent failure rate might also be being skewed by other details of your implementation. I've filed a bug on this already (r.172771068), but I'd appreciate your filing your own bug and posting the bug number back here. I would like to confirm if the result of SHARED REPLY TIMING with Warning is not an issue and can still result to BCT certification to Pass. This warning is not an

Hello @iiil8 I would like to take a look at this. Can you file a report with Feedback Assistant https://developer.apple.com/feedback-assistant/ and attach a minimal sample project that reproduces this issue? Please reply with the FB number once complete.

Could you please file a feedback report and include the sample code that reproduces the issue. Once you do please share the Feedback ID number here for the record. Thanks