smb big sur

On macOS 13 (and possibly earlier), sometimes these calls get stuck and never return. When this happens, the kernel will kill the extension and this generates a crash log. First off, if you have crash logs then I'd like to see them. I'm fairly confident I understand what's going on (see below) but it's always worth seeing what the log(s) show. A couple of the checks we do require calling into Apple frameworks (Security, Disk Arbitration) and these checks can happen early in the boot process. The words early in the boot process... can be a BIG red flag when it comes to an ESE. Particularly if you're using NSEndpointSecurityEarlyBoot, early can be very, VERY early, opening the door to all sort of unexpected issues. Case in point, on it's own diskarbitrationd (the daemon underneath the DiskArb framework) doesn't actually need to run all that early in the boot process. The boot device mounts without it and there generally isn't an urgent need to automount other volumes until later in the process. One sim

Sporadically, I'm seeing an issue where some of the network requests succeed, but anything involving reading from disc does not load immediately. So the big questions here is where was that data actually stored? Practically speaking, there are ~4 broad sources of file data, roughly sorted by performance (fastest-> slowest): The direct, local storage (flash) of the device. Storage (hard drive) directly attached to the device. Network file systems (SMB). Cloud storage (iCloud Drive and 3rd party storage). Critically, 1 & 2 are FAR faster than the other two, particularly #1. The performance of #3 is EXTREMELY variable, running from as fast or faster then #2 to arbitrarily slow. However, that performance tends to be relatively stable (it isn't slow then suddenly fast) and, more importantly, users interacting with this kind of storage generally aren't surprised/annoyed by it. In concrete terms, when I'm downloading a critical file over a terrible connection I don't blame the app when it t

First, off I want to focus on these details: Mounting SMB and AFP shares always works without issues. The app is properly sandboxed. and this error: System Policy: webdavfs_agent() deny(1) file-mount ...I don’t see any reason why they would affect only WebDAV mounting while everything else works fine. Agreed. Please file a bug on this and then post the bug number back here. Setting all other issues aside, I can't think of any case where the system should deny mounting for webdav but allow SMB/AFP. This is a case where they should either all fail or all succeed. Next a few clarification on other points: I’d prefer not to recreate all my certificates and configurations, as I don’t see any reason why they would affect only WebDAV mounting while everything else works fine. For future reference, there's generally not any reason to bother with this sort of recreate everything. You can basically split our codesigning architecture around two questions: Is the signature valid? -> If it is, let the

The only way to force a release of an autoreleased object is to create your own autorelease pool with a smaller scope. In theory, you can use the method names to determine ownership and responsibilities. The documentation usually tells you too. With modern ARC code, it usually isn't too big of a problem.

Thanks! We also managed to confirm that by reading libdispatch source code in apple-oss-distributons repo. My original interest in this topic was slightly different. Originally, I was investigating a bug in our product that was not triggered until very recently. We had an command-line executable running as a launch agent that was preforming some setup and then calling dispatch_main to prevent the process from terminating. The bug was caused by important bit of code that was put below dispatch_main in main.swift. This was the setup roughly. All happening in main.swift without dispatching to any other thread. // 1. setup environment // 2. call dispatch_main // 3. additional setup The problem is that the code was reaching 3. additional setup areas before recent changes. And it was a big WTF moment of why it suddenly stopped working. Now that I am looking at this code, it makes perfect sense. It should have never reached anything after dispatch_main. Nothing in this original setup in main.swift was touch

I’m not a big for of SMJobSubmit. I understand why folks use it, but I’m unconvinced that it’s better than SMJobBless. Most apps that update themselves want to be able to do this repeatedly, and SMJobBless facilitates that. [quote='822885022, berd-lp, /thread/773344?answerId=822885022#822885022, /profile/berd-lp'] Only App Bundle Protection would prevent someone from doing this [/quote] App bundle protection is kinda key. I only see two ways to solve this problem properly: SMJobBless, which makes a copy and then checks the copy Relying on app data protection Everything else suffers from at TOC/TOU, at least. However, I agree that there are two levels of threat here: Replacing the executable at any time Replacing the executable at just the right time to hit the TOC/TOU window The latter is much harder to pull off in practice. Which brings us back to your original question. If you want to check that your helper tool is the code that you think it is — while acknowledging that your check is subject to TO

[quote='822883022, tuhinkumar, /thread/773326?answerId=822883022#822883022, /profile/tuhinkumar'] My previous understanding was that the copying to the send-buffer itself will be deferred. [/quote] I think that’s a distinction that makes no difference in practice. Under the covers Network framework works with dispatch_data_t objects. Those are immutable. When you pass data to a send routine, it retains the object until it’s done with the data. Exactly when that happens is an implementation detail. Critically, you might see different behaviour with each networking stack: With the in-kernel networking stack, the data must eventually get copied into a socket buffer, at which point the data object could be released. With the user-space networking stack, you could imagine it using the data object as the socket buffer. IMPORTANT I’m not saying that this is how it currently works; rather I’m pointing out how the implementation could differ and still maintain the current API. [quote='822883022, tuhinkumar, /thread/77

Bienvenue sur le forum. Probablement une donnée incorrecte dans un des champs. A quelle étape ce message se produit il ? Pouvez vous poster une copie d'écran de la page où cela se produit (n'oubliez pas de masquer toute information personnelle) ? Vous pouvez aussi contacter le support. https://developer.apple.com/contact/topic/select Et sélectionner Programme d'inscription.

Identify attributes similar to cloud/offline storage status for files in synced drives (e.g., OneDrive, DropBox etc). Retrieve metadata to distinguish files/folders stored locally versus those stored remotely and downloaded on access. First off, there are actually two different cases the can happen here depending on the product, system version, etc: Historically, products like this were implemented by either using kauth, the VFS layer (most commonly, through FUSE), or through a loopback SMB server. The kauth API has been deprecated long enough that I don't think you'll run into that case anymore, but the other two cases still exist in the wild. The modern approach is to use NSFileProviderReplicatedExtension to integrate into with the system. As far as the system is concerned, we only have API support for #2. The first case is either totally invisible (kauth) or can't be differentiated for other use cases of the same file system APIs. SO, focusing on #2: If there’s a preferred macOS framework (like Co

Hey thanks for the great question! The sounds and haptics you hear and feel from VoiceOver are controlled by the system. There is not an interface for third party apps to instruct VoiceOver to play certain sounds necessarily. When a screen changed notification gets sent to VoiceOver for example, the system plays a sound to let the user know a big layout change occurred and that the VoiceOver cursor is getting repositioned. In a sense you can accomplish this too in your app by posting a screen changed or layout changed notification, but in terms of playing other sounds for new rows, entering/exiting containers, or interacting with pop up menus are not sounds you can play explicitly.

Within Network framework, every connection has a send buffer [1]. That buffer has a high-water mark, that is, its expected maximum size. When you send data on the connection, the system always adds the data to the buffer. After that, one of two things happens: If the amount of buffered data is below the high-water mark, the system immediately calls the completion handler associated with the send. If not, it defers calling your completion handler. That is, it holds to on the completion handler and only calls it once the amount of buffered data has dropped to a reasonable level. If you have a lot of data to send, the easiest approach is to send a chunk of data and, in the completion handler, send the next chunk. Assuming the network is consuming data slower than you’re producing it, the amount of buffered data will rapidly increase until it exceeds the high-water mark. At that point the system will stop calling your completion handler, which means you’ll stop sending new data. This gives the network tranport a