smb big sur

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

It's more likely that Finder is calling a network-specific file operation for the SMB or AFP connection. You said you could work around the problem by manually doing a recursive delete. But does that mean that this actually works? Permissions can be complicated, especially on a Linux-based file server that the user could have configured in an unusual fashion.

Since installing beta 3, literally every single request I send to Foundation Models generates a guardrails error where before it was about 10%. Since we don't have Xcode yet, I haven't re-tested my evals but it seems like something really big changed in this seed. I would call it a big regression to the point of no longer being unusable.