“smb big sur”

Sorry, it was a TSI, not a bug report. I replied to the DTS email yesterday with the full spin dump. Ahh, I see it now. So, the first thing I actually did was search for /usr/lib/libEndpointSecurity.dylib (the library link path), which is a convenient way to find all ES clients. What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. That's a critical factor here because it means that there are now two independent entities with veto power over each other's activities, particularly activity that's coming from helper components (not just the direct ES client). That leads to here: There are only 2 other threads in the logs that appear relevant, both from our helper process and both down in APFS. One of them is also stuck inside decmpfs_read_compressed: That's the deadlock. More specifically, looking at your thread's stack when you enter decmpfs_read_compressed, the first thing it does is call decmpfs_lock_compressed_data: (1) *940 decmpfs_read_compressed + 300 (kernel

I briefly thought about this though I wasn't sure how path control grabs the icons (through the URL or something else like NSWorkspace) and I wanted to have that in the bg too. Strictly speaking, it uses NSWorkspace.icon(forFile:) but that doesn't really matter at least as far as display works. The rules for EXACTLY which icon will be shown for every possible edge case are sufficiently complex that the only way to ensure consistent behavior is to have a bottleneck through a single API. So NSWorkspace.icon(forFile:) and NSURLEffectiveIconKey are both calling into the same place (currently a private SPI in LaunchServices). I hadn't actually noticed that we'd deprecated kCFURLEffectiveIconKey; however, that doesn't actually change anything about using CFURL. The point of toll-free bridged objects is that the two types should act as full replacements for each other, so you can pass NSURLEffectiveIconKey[1] directly into CFURL. Under normal conditions this isn't a big deal but dealing with a URL on a slow

Not really. That is, you might be able to subclass the control to get the behavior you want; however, I think the work involved would be fairly similar making your own control using our view components. True. Yea it isn't too much work. Just needed to fetch the titles and the icon images in the background. but CFURL does NOT, I briefly thought about this though I wasn't sure how path control grabs the icons (through the url or something else like NSWorkspace) and I wanted to have that in the bg too. Under normal conditions this isn't a big deal but dealing with a url on a slow network it can cause a little hitch, as I discovered!

[quote='820155021, alex_strong, /thread/820155, /profile/alex_strong'] I've had issues getting the dmg signed by the Apple notary service [/quote] That text suggests that you’ve misunderstood how notary works. The notary service doesn’t sign your product. Rather, you present it with a distribution-ready product, one that’s already signed, and the notary service checks it and, if all is well, issues a signed ticket. See Notarisation Fundamentals for more about how this process works. As to why the notary service is refusing to notarise your product, it’s hard to say without more info. It sounds like you were able to submit the product and get a response, but the status is Invalid, indicating a problem with your submission. In that case the next step is to look at the notary log. What does it say? See Fetching the Notary Log for info on how to get the log. [quote='820155021, alex_strong, /thread/820155, /profile/alex_strong'] The only big change we made this time was switching to Maven [/quote] Ah, Jav

I want to be clear about terminology here: A load-time import is one that’s statically declared in the binary via the LC_LOAD_DYLIB load command. A run-time import is one that you do from code, using dlopen or some API layered on top of that. Beyond that, I’m going to use the terms from an An Apple Library Primer, and you should read before continuing. [quote='820251021, vd02, /thread/820251, /profile/vd02'] What is the recommended approach on macOS for this kind of explicit dynamic loading … ? [/quote] My recommendation is that you not do this. Apple platforms generally prefer load-time imports because it enables optimisations in the dynamic linker. Specifically, the dynamic linker can build and cache a closure for an app, reusing that closure the next time the app launches. Note We discussed this in detail in WWDC 2017 Session 413 App Startup Time: Past, Present, and Future. Sadly, it’s no longer available from Apple, but the core info is still available from third-party sources. I don’t think this closure

It’s hard to answer questions like this without knowing more about: The platforms you’re targeting — Features like this aren’t part of the Swift language, but rather come from the platform on which your code is running. So you’ll get different answers on, say, Apple platforms vs Linux or Windows. The data itself — How big is it? Does it have some sort of complex structure? Your sharing scope — Do you just want to store it on the device? Or share it between devices owned by the same user? Or share it between users? The operations on that data — Do you write to it more than you read? Do you need to issue complex queries against it? The threat model — Are you trying to prevent accidental leaks? Or protect the data from government-sponsor attackers? Or something in between? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Git repos can be big source of this problem. But there's one more to check. Xcode projects actually consist of two parts - the project and the workspace. The source code integrations are based on the workspace. Xcode uses a shared workspace by default. But you can create a dedicated workspace file for your project and then just open that file instead of the project file.

[quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] I need to support both use case (exec and dylib). [/quote] OK. [quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] [Library validation] does not apply in my scenario since the library is provided by a third party [/quote] I’d like to better understand that. It’s quite common for Mac apps to use libraries created by other developers, and they retain library validation by re-signing those libraries. Is there something preventing you from doing that in this case? The most obvious case where folks need to disable library validation is that their app supports in-process plug-ins, where those plug-ins are built and shipped by other third-party developers in a way that’s completely independent of the main app’s vendor. Is that what’s happening here? Because if you’re managing these plug-in releases then it’d be better to have you re-sign the plug-in and leave library validation enab

> I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route? Depends on exactly what your needs are and the hardware you're working with. Starting with MFi, the biggest advantage is that the software side (ExternalAccessory framework) is far simpler to use and includes support for background access (DriverKit does not). The main downside is that it requires a certain amount of custom hardware and the certification process. Comparing it with DriverKit is... complicated. The software side of DriverKit is FAR more complicated. To start with, the DriverKit API is a somewhat odd derivative of the IOKit kernel API. For someone who's familiar with IOKit, it's similar enough to be understandable, but for a new developer, the learning curve can be quite significant. None of this is helped by the fact that DriverKit is poorly documented[1], to the point that my standard advice to new developers is to study the IOKit kernel API (which has o

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 the copied file vali

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 attachment o

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 previously described above. Yes. For complicated historical reas

[quote='880167022, parker9, /thread/810258?answerId=880167022#880167022, /profile/parker9'] GitHub has the actual source for that version in Releases [/quote] OK. I downloaded the app, the .dSYM, and the source code and took a look. First, the crash report has this: Binary Images: 0x102c6c000 - 0x102c9ffff DIM arm64 <3e247524da7930099f63cd12ace4ab0e> …/DIM I used dwarfdump to confirm that I have the right .dSYM: % dwarfdump --uuid DIM.app/Contents/MacOS/DIM UUID: 7A4DAC69-55A2-3D1B-B9E0-6A14AB2D5EEA (x86_64) DIM.app/Contents/MacOS/DIM UUID: 3E247524-DA79-3009-9F63-CD12ACE4AB0E (arm64) DIM.app/Contents/MacOS/DIM I then symbolicated those frames: % atos -l 0x102c6c000 -o DIM.app.dSYM 0x102c799bc 0x102c8b4d4 closure #1 in ViewController.restore(_:) (in DIM) (ViewController.swift:207) thunk for @escaping @callee_guaranteed () -> () (in DIM) + 28 Plugging that into the backtrace, I get this: Thread 1 Crashed:: Dispatch queue: com.apple.root.utility-qos 0 DIM … 0x102c6c000 + 55740 closure #1 in ViewControl

Hi, my app has been validated but still not available in France because its still in verification for that point : La législation sur les services numériques. Regards