smb big sur

I’d like to clarify your setup. Specifically, I’d like to get a better understanding of the actors involved. You mentioned: Your “client server application” “a file server on the same machine” Copying “using using Finder or terminal using cp” So, is your client/server app one app? Or two? And is the server running locally as well? Or just the client? Is the client/server app related to the file server? Or are you using some standard file server protocol, like SMB? And if it’s a standard file server protocol, are you using the built-in client and server implementations? Or something custom? Also, what version of macOS is this? And do you see any crash reports generated at the time you see this error? Oh, and some random notes… I’m not sure where you got EBROKENPIPE from. The error I’d expect to see when you write to a disconnected socket [1] is EPIPE (32). [quote='794958021, bilbo42, /thread/794958, /profile/bilbo42'] necp_socket_find_policy_match: Marking socket in state 258 as defunct [/quote] NECP

Aren't new features the same as enhancements? Usually the delicate part is bug fixes. Those would get applied to older, currently shipping code. You could do them either in a branch or in main, but the idea is that, one way or another, bug fixes will relatively quickly update the main branch. Then the delicate part is making sure that any pending branches are compatible with those bug fixes. In theory, since they're still pending, that's easy to do. At that point, you know about the bug and can fix any new code, while merging the fixes in the new main. But it's all based on what you're comfortable with and what you can manage. Working as a lone developer, I wouldn't do a new branch for anything unless it was going to require weeks of effort and/or substantial changes/extensive testing. But back in the day, with 600 developers on a project, everything went into its own branch and the SCM team managed that. Testing was no big deal because we had a very large testing group and months-long test procedure

[quote='850527022, Costique, /thread/794052?answerId=850527022#850527022, /profile/Costique'] all we have is crash reports from the App Store in Xcode. [/quote] Hmmm. This is using the Xcode organiser, right? I thought that had a way to get a JSON crash report, but I don’t have the details. I’m researching that. The reason why a JSON crash report is so helpful is that I can feed it into internal tools to look for related crashes. [quote='850527022, Costique, /thread/794052?answerId=850527022#850527022, /profile/Costique'] What surprises me a bit is Role: Non UI in all but one crash instance though the app does not use any background modes. [/quote] Well, as we say in the docs: This field is generally not helpful when you analyze a crash report. (-: Even if you don’t do anything to opt in to background execution, it’s still possible to run in the background. The most obvious case of this is that the system gives you a short amount of background execution time after you move to the background and it’s delivered

Buttons with text labels are not merged with buttons with images. This is documented somewhere or mentioned in one of the WWDC 2025 videos (I forget which one). Here's a big question for you - how did you get the Back button tinted? As of iOS 26.0 beta 4, there is no way to tint a standard back button. Did you add your own button to look and work like a back button?

Thank you Quinn (big fan btw), I have tried to do it with an extension, which works surprisingly well, but for some reason the only way to get it to truly work was to present the remote view (tried both NSView/Controller representables) inside a popup. Trying to directly include it in the hierarchy results in a stale view (shows up the content but cannot be interacted with).

First, jumping back to the testing side, have you specifically confirmed in your VM that you see the same problem when you login an admin user, followed by standard user. I want to be clear on this point because with any macOS investigation it's CRITICAL to differentiate between: A general issue that's happening on a broad set of machines configured in a specific, controlled way. A specific issue that's happening on a particular machine. The difference here is critical as it completely changes how you focus the investigation. In the first case, the focus is on finding out what makes your app different (because something about it is confusing the machine), while the second case is about what makes this machine different. We didnt have 2 sessions of our plug-in/Photoshop being invoked. The admin user was just physically logged in for other purposes. So, only 1 instance was running of Photoshop/our plug-in/background process always under the Standard user account. Huh. First off, how exactly does your plug-in ru

First off, ruling an issue out here: However, when our tool is installed from a Standard Account, the macOS messages asking for confirmation to access the Desktop or Documents or Downloads folder don’t appear and access to the file/folders is denied. Does your app include all of the relevant tcc strings (NSDesktopFolderUsageDescription, etc.)? Also, one thing to be careful of here is that there are a bunch of heuristics in this system that control how/when these are presented, which can make knowing why something is working a particular way difficult to determine. When you're looking closely at an issue like this, I'd always suggest working on a totally clean machine*, not your normal development machine. *VMs are handy for this, as you can get the system to a fully configured state, then duplicate the VM image so you can always start over from the same exact starting point. We install a Photoshop plug-in and it’s mainly a UI which then executes a background app containing the business logic to read/write fil

Good guess, but that wasn't the issue, even though it would have made a lot of sense. It's unfortunate I left that part of the code in there, but the user actually tested my App Store app with and without unlocking locked files (the app contains a switch for that), which didn't help, and they sent me plenty of screenshots and videos which show that the files are not locked. So, I took another pass at this and I think I found the problem. There is actually a known bug (r.129627798) similar to this in our smb server that was fixed in macOS 26. Basically, the way delete works in smb is that the client accesses the file with a DELETE_ON_CLOSE option, then closes the file to trigger the delete. The server tracks open file references and then deletes the file when the count reaches 0. Unfortunately, there was an issue in our file closing logic which could cause the server to keep the count high longer than it should, leading to the problem you're seeing. I've mentioned that this was happening on o

Regarding the big picture issue here, I believe that this is working as designed [1]. If you’d like to see that change, my advice is that you file a bug report explaining your concern.. Please post your bug number, just for the record. [quote='793415021, ss_couto, /thread/793415, /profile/ss_couto'] What exactly is the authorization session mentioned in /System/Library/Security/authorization.plist? [/quote] This refers to the security session, which is roughly equivalent to the login session. [quote='793415021, ss_couto, /thread/793415, /profile/ss_couto'] QA 1277 [/quote] It’s hard to believe that this is the second time that truly ancient Q&A has come up in the past few weeks. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] If you look at the design of System Preferences on early versions of Mac OS X, various panels have a lock icon. That reflects the state of the admin credentials. If you’re logged in as a standard user a

So, there are actually a few different things at work here. First of the errors here: /usr/local/mnt: No such file or directory ...means exactly what it sounds like. You specified the mount target (the point the new file system would attach on your file system) as /usr/local/mnt/ and that directory either does not exist or you don't have permission to it. That's what I'd expect, as that's not a standard macOS directory, so it won't exist unless you create it. The solution is to create the directory, change the permissions, or pick a new directory. I'm not familiar with how Time Machine on a NAS works I believe we still create disk images, which are then mounted and treated as local backup target volumes. That means there are actually two permission systems at work here: The permission of the smb volume the NAS device shares. The permission of the TimeMachine disk image. That difference is important, because it leads to the difference in behavior between this case: This was on a USB drive mounted with