smb big sur

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

Perhaps the only remaining question would be: how would I find out if the Carbon API / the SMB volume effectively supports cloning, or is it not possible? That's a tricky one, as you have very little ability to interrogate the target system and can't really determine what's on the other side. If VOL_CAP_INT_COPYFILE* is false then you know that it won't work but that doesn't cover cases like the remote volume being an HFS+ volume (not APFS). *As backstory, yes, there are in fact two totally different functions in the system which were both called copyfile(). One is the public API, the other is a private syscall hook to the VNOP_COPYFILE VFS hook. Note that afp (Apple File Sharing Protocol, NOT APFS-> Apple File System) and smb are currently the ONLY file systems that implement VNOP_COPYFILE. The history here is that a VERY long time ago VNOP_COPYFILE was originally added to support AFP (which is where the do the copy on the server idea came from) and SMB picked it up later to pro

@DTS Engineer I think that I got general understanding of the issue that occurs. In our application we still depend on TVML Kit (which is marked as deprecated already). On many screens we use the stackTemplate with collectionList that contains big numer of shelfs (10-20) with lockups that allow to horizontally scroll the rows. Based on investigation of what is going on with memory I see that TVML engine does its best to speedup the process of rendering the lockup elements to provide the best experience while doing the quick scroll through the all shelfs. To handle it, the TVML uses some kind of rasterisation mechanism for TVML elements and display them as a single image in TVStackedImageView. It leads to issues in case of using the first generation of apple TV as rastered elements are kept in memory as long as the template keeps alive. There is a big difference in memory consumptions in case of using 4k display and 1080p. It seems to be related to fact that created images for 4K displays are

I see, thanks. I'd prefer to stay away from deprecated APIs, but if a user complains about the speed when copying between SMB volumes, I'll come back to this topic. Perhaps the only remaining question would be: how would I find out if the Carbon API / the SMB volume effectively supports cloning, or is it not possible?

I don't understand. Doesn't URLResourceKey.volumeSupportsFileCloningKey allow me to detect if cloning is supported? It does, and I think you'll find that it returns false when called on any SMB volume. I thought you were saying that with the deprecated Carbon API one can clone files, but then I don't understand why file clones are not preserved. Do you mean when copying a folder that contains file clones, those files are copied and not cloned? First of all, please try this with Finder paying attention to what you're doing and how it affects storage usage on the server. I've explained what's going on below, but it will make a lot more sense when you do the testing yourself. So, there are two different cases here: Copy from the local device to the remote server. Copying contents within a volume on the remote server. For case #1, the Carbon API and our other copy APIs have the same behavior and similar performance (if anything, Carbon will be slightly slower). As part of that, cloned files will be lost

[quote='848663022, DTS Engineer, /thread/791665?answerId=848663022#848663022'] This is a known limitation of the macOS smb client [/quote] Thanks for confirming. Hopefully one day it will be implemented. I created FB18783115.

This is a known limitation of the macOS smb client (r.67464389), however, it may work on iOS (which has a somewhat different SMB implementation) assuming the server declares support for hard links. __ Kevin Elliott DTS Engineer, CoreOS/Hardware