smb big sur

So, first off, I want to clarify that the issue ISN'T this: Every time I disconnect and reconnect to the server, selecting the same file returns a different path. The first time I got Bookmark resolution does not depend on the mount (or full) path and never has. While the full path on macOS tends to be relatively stable, that's simply a side effect of the macOS volume mounting convention, NOT something the bookmark system actually relies on. You can easily prove this yourself by setting up two different SMB shares that with names such that they both mount as foo. Whichever is mounted first will mount /Volumes/foo/ and the second will mount at /Volumes/foo 1/. If you create a boomark to an object bar on one of those two shares, then macOS will happily resolve the bookmark to that object to either /Volumes/foo/bar or /Volumes/foo 1/bar, depending on which order the shares happen to have been mounted when you resolve the bookmark. That leads to here: Is it not possible to automatically mount a server wh

For what it is worth, I just updated my iphone XR from IOS 17.7.2 to 18.3 and regret it, not only due to the horrid Photos app, but relevant here, Battery drain is significantly increased. Up through IOS 17.7.2, battery drain was never more than 2-4% per-day. I don't use the phone much other than to check a message or transfer a file or photo from the PC to the phone or vice-versa using Files over smb. After update to 18.3, battery drain jumped to 13-15% per-day with the same average use. That is a 3-5 fold increase in battery drain. I've disabled the privacy invading scan my photos for landmarks, and since this phone isn't AI capable, the AI nonsense shouldn't be causing additional battery drain -- but something is -- and it is significant. Take this as another data-point on the 18.3 battery-drain issue. There really is no reason I should see increased battery-drain on an XR, but it is significant. The only other issue that may be related to the drain is I've noticed touch-sensitivity is wildly high

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.