“smb big sur”

This issue is still ongoing. Thus far we have not been able to figure out what is going on but have reduced complaints quite a bit by rolling back to minimum OS / Devkit of iOS 17. So it is some kind of bug or behavioral issue with iOS 18 SDK. We cannot find a pattern to it other than that most users are in Europe and are not using iCloud to backup. This means we are using the NSPersistentCloudKitContainer regardless of if users enable or do not enable iCloud usage. This might be the root so if anyone is aware of what might have changed in iOS 18 that would do this PLEASE let me know. We have also now default always enable iCloud usage without asking if we find an account present. They can turn it off (with big warnings) if they want but we no longer ask on launch. Also we will investigate not always using NSPersistentCloudKitContainer if iCloud is not used.

I have been sitting with samba and my driver with dtrace for around a week, comparing every field and every return code. So, the risk with this kind of comparison are details (and differences) like these: I do not have MNT_DOVOLFS in mount flags. AND For persistent object ids (VOL_CAP_FMT_PERSISTENTOBJECTIDS), I do have this one enabled, however, I am not sure I am doing anything to actually support it. The behavior of a VFS driver isn't just determined by the data it directly returns. The details of how you describe your own capabilities to the system because the can and will change: How the VFS system interact with your driver and interprets your data. How user space process choose to interact with your files system. Claiming your files system support a capability it does not will create EXACTLY the kind of problem you're seeing. Based on what you're said here: Afterwards, even renavigating back to my root will not work inside Adobe - the driver will simply represent itself as empty. I'd also sugge

Thanks a lot in the first place. What does the interface for this actually look like? Is it presenting its own file navigation UI (I suspect yes) or is this the open/save panel? Similarly, when looking at the other things you tested: You are right, that most apps like Word, Safari and other applications that I have tested indeed use system-like navigation, with open/save buttons, while this program indeed has a separate UI, listing only media files and directories and it is simply different from Finder UI. Regarding the cases you have asked to test. Setup as controlled a test as you possibly can, with minimal directory contents and external interactions. The ideal here is that the ONLY VFS activity that's occurring is coming directly from the app your trying to understand. You can often figure out what's going on by first isolating the issue (as above) then closely examining EXACTLY what every vfs operation returned. I have been sitting with samba and my driver with dtrace for around a week, comparin

I tend to disagree with it just being a USB connection. If you purchase a thundebolt cable and connect it to a mac with a thunderbolt port, there is a big difference in connection speed. I use it daily as a virtual screen for my macbook pro and compared to the wireless network (I have an Orbi 970 series), it connects way faster. I don't experience any lag at all. The best benefit for me is that I can use it as a virtual display at a coffee shop (coffee shop name not mentioned), I am not limited to the connection of their wireless bandwidth which is typically slow. Transferring files is also blazingly fast. Again, try using a thundebolt cable and you'd feel the difference.

Upon using some graphical apps, for example Adobe Media Encoder, attempting to navigate inside my filesystem deeper than root folder will fail What does the interface for this actually look like? Is it presenting it's own file navigation UI (I suspect yes) or is this the open/save panel? Similarly, when looking at the other things you tested: The problem is not present for most GUI apps - for example navigation inside Finder, upon choosing download path for file in Safari, apps like Microsoft Word, Excel and other range of applications work totally correctly. Did any of those (aside from the Finder) actually present file navigation UI or did they rely on the system panels? The reason this matters is that the system interface elements are all going to channel into fairly narrow API range. Most likely one or more getattrlistbulk calls (to retrieve directory contents) which would eventually return a file reference URL. That would then lead to: A quick note here. From what I have seen - all apps that work correct

Can concur that I'm having the same issue- a @Query sort descriptor is causing my app to crash on launch, and the issue only began on iOS 18.3. Frustratingly enough, it doesn't happen when I build and install the app through Xcode, even on a Release configuration. I thought that it was fixed by just recompiling with a newer version of Xcode (I had built and submitted my app a few months ago) and it even passed the app store review, so I guess they're not using the latest version of iOS?? I'm very frustrated by this regression- I have a big marketing push scheduled for my app and this is the absolute worst timing for such an issue to come up. Now I have to wrangle with manually archiving and sideloading my app just to test whether a fix is working. Frankly, iOS 18's entire release cycle has just been a disaster. One of the buggiest things I've ever had the displeasure to deal with. Feels like this isn't the same Apple- even 2 years ago it feels like they'd never let such a buggy release like this happ

I understand that RPC is not the recommended IPC mechanism for communication between an Endpoint Security (ES) Extension or a Network System Extension and a daemon. First off, it's important to be clear about what our recommendations here really mean. Our standard IPC recommendation is XPC. That's because it's a good API with very high performance. Many applications (including ESE's) use sockets (generally Unix, sometimes IP), typically because it's either part of an existing implementation (often cross platform) or because the technical details mean that there isn't a good way to get an XPC connection. I consider both of those APIs to be very reasonable solution and could happily argue for or against either one of them, depending on the context and use case. We do (quite strongly) recommend against trying to use mach ports directly and that's because XPC provides the same capability and experience has shown that the mach API is nearly impossible to use properly. However, the issue ESE's have isn't API choice

You said that this bug was fixed in macOS 13 Ventura, but i'm currently on macOS Ventura now and experience this bug. No, that's not what I said. I said, One notorious bug was the case of the disappearing Safari extensions, introduced in macOS 11 Big Sur and finally fixed in macOS 13 Ventura. In this blog post, I'll discuss a current bug [emphasis added] involving multiple versions of the same app installed on one Mac.

On macOS, we have didMountNotification but there doesn't seem to be an equivalent for iOS. Is there a way to be notified when a volume is mounted on iOS? There is not. It's reasonable enhancement request, however, I'm afraid that it wouldn't be all that useful even if it did exist. That's because of issue with the next stage here: I would like to use it in my iOS app I'm currently porting from macOS, which starts a synchronization from the volume (which has been previously selected in a NSOpenPanel) as soon as it's mounted. On macOS, you did this by creating a security scoped bookmark to the target directory. Unfortunately, cross volume bookmark resolution is broken on iOS (r.102995804). The bookmark itself will work fine as long as the volume is mounted but this longer sequence: Mount an external volume. Bookmark an object on that share. Unmount that external volume in Files.app. Remount that external volume in Files.app. Resolve the bookmark (which will fail). ...fails on iOS 16 or later. This will occur on

On macOS, we have didMountNotification but there doesn't seem to be an equivalent for iOS. Is there a way to be notified when a volume is mounted on iOS? There is not. It's reasonable enhancement request, however, I'm afraid that, unfortunately, it wouldn't be all that useful even if it did exist. That's because of issue with the next stage here: I would like to use it in my iOS app I'm currently porting from macOS, which starts a synchronization from the volume (which has been previously selected in a NSOpenPanel) as soon as it's mounted. On macOS, you did this by creating a security scoped bookmark to the target directory. Unfortunately, cross volume bookmark resolution is broken on iOS (r.102995804). The bookmark itself will work fine as long as the volume is mounted but this longer sequence: Mount an external volume. Bookmark an object on that share. Unmount that external volume in Files.app. Remount that external volume in Files.app. Resolve the bookmark (which will fail). ...fails on iOS 16 or later. Th

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