smb big sur

You don't want to end up unnecessarily copying to the system volume when you could have cloned by staying inside the correct file system. I don't understand. Doesn't URLResourceKey.volumeSupportsFileCloningKey allow me to detect if cloning is supported? on the smb side, I don't think there's currently any way to preserve file clones across the smb copy, even when both sides support cloning 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?

It’s a conditional operator that takes three inputs, so calling it ternary conditional operator doesn’t seem like a big stretch. Regardless, I’m not the person you need to convince here. If you want to discuss this with Swift language folks, I recommend that you bounce over to Swift Evolution. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, We were successfully able to mount an SMB network share using its IPv6 address. We tried mounting SMB via Finder as well as NetFSMountURLSync and it worked. How is SMB mount working? The NetFS framework is actually a relatively thin wrapper on top of individual NetFSPlugins written as part of each network file system driver. Case in point, while this log message: GetServerInfo failed with error 5 ...did come from the NetFS framework, the function that actually returned 5 was the WebDAVPlugin implementation of GetServerInfo. That leads back to here: How is SMB mount working? I haven't looked at their code in detail, but the high-level answer is that they're totally different code paths. smb's URL structure is more complicated and the smb project is under much more active development, both of which probably helped avoid the problem. I will say that some work was done ~15 years to support IPv6 URLs as part of our transition from afp to smb, but t

I started with a sequenced DragGesture and ran into the same problem: no way to get the start location (before the drag starts). Then I tried using .simultaneously instead of .sequenced: let longPressDrag = LongPressGesture(minimumDuration: 0.2) .onEnded { value in } .simultaneously(with: dragGesture) .updating($state, body: { value, state, trans in dragStartLocation = value.second?.location ?? .zero }) .onEnded({ value in dragStartLocation = .zero }) This kind of works: the LongPressGesture sets dragStartLocation (before releasing the touch or dragging). I'm using this with a ScrollView. If I quickly drag, the ScrollView scrolls. If I touch, then wait before dragging, I can set scrollDisabled on the ScrollView and the DragGesture takes over. Unfortunately, there's one big problem: the LongPressGesture always takes 1 second to process. It doesn't matter if minimumDuration is set to 0.1 seconds or 10 seconds. So we're left with two undesirable options: Use a sequenced gesture, which uses the correct m

Hi, We were successfully able to mount an SMB network share using its IPv6 address. We tried mounting SMB via Finder as well as NetFSMountURLSync and it worked. How is SMB mount working?

Thanks. Sure, I just meant that it seems a little unclean to have a temporary file on a volume that is not controlled by the OS and could potentially be lying there forever if the volume is disconnected in the middle of the operation. There's a forum post I did here about the choice between using the directory returned by url(for:in:appropriateFor:create:) vs creating your own user-visible directory, but the bottom line is that there isn't really any single, right answer to this question. You're going to leave data behind if the operation is interrupted, and you have to decide whether it's better to: Make things seamless by minimizing user involvement, but risk orphaning data in ways that aren't necessarily visible to the user. Complicate the experience by making what you're doing visible to the user. The right choice here depends entirely on the details of the product you’re building. I'm going to be using URLResourceKey.volumeSupportsFileCloningKey to determine if cloning is available and use clonefile in t

I am working on an app (iOS, iPadOS & macOS (Mac Catalyst)) for a Home Automation device. I am using HomeKit APIs to access commissioned devices and provided APIs to get a MatterNodeID and then a MTRBaseDevice so I can query the device. Since the current APIs for accessing Matter devices this way do not support subscriptions, I am using the readAttributes() method of the MTRBaseDevice to get information from the device. There can be significant lag time in these reads, and I realize my network speed and congestion can contribute to this. What are the final endpoints you're interacting with and, in particular, are they using Thread? On top of the fixed cost (more on that shortly), Thread accessories tend to increase latency. Part of that is that extra layer of the thread bridge and lower bandwidth, but most of that is that the accessory itself, particularly for things like battery-powered sensors or buttons. In concrete terms, there is a pretty big performance spectrum between: A wall-powered Matt

First off, a warning on ANY usage of URL.path() and string-based paths in general. Basically, the existence of string paths in our API is a fundamental design mistake we made 25+ years ago and have been paying for ever since. The issue isn't all that visible because actually relying on normalization sensitivity is a fairly terrible idea, not because the system actually handles this case properly. In addition, there are places in our API like file iteration where the path variant is MUCH worse than the URL equivalent. In any case, I recommend avoiding string paths wherever possible. Kevin, this is helpful information. Just to make sure I'm reading you correctly, is it a valid approach to copy the file into your sandboxed app directory (e.g. the app's documents folder) to Quick Look, and then remove it once you're done with Quick Look? Yes, but with the qualifiers: Things get a lot more complicated if/when you're crossing volumes, something which isn't necessarily obvious without a lot of additional checking. Y