smb big sur

Answer Two, A completely different theory: SO, my other answer is a perfect example of two things: Sometimes it better to be lucky than good. In an investigation like this, the MOST important thing is to not assume you understand the problem. Focusing on to much on what the problem is can very well mean you miss the entire problem. Point 1: This morning I was look at a completely unrelated problem from a totally different developer. This particular problem happened to involve a file system performance problem for a single user who had recently upgraded to macOS 14.7.1. I was looking in the the activity of an endpoint security client (more on why later) and, as part of that, I put the bundle of ID of from that ES client into Spotlight, which happily searched my entire hard drive (I hadn't restricted it to the sysdiagnose log). What it found was a spindump log from that ES client inside YOUR sysdiagnose file (the name starts with RTProtectionDaemon). Point 2: Because of the overall context, my focus here has be

Answer One, a possible work around: While looking through the log again today, I think I actually found the point the problem occurs, which is this log sequence: 2024-10-27 19:48:02.915-0400 kernel smbfs_enum_dir: Resuming enumeration for 2024-10-27 19:48:02.915-0400 kernel smbfs_find_cookie: Key 5, offset 1130, nodeID 0x400000007bd6c name for 2024-10-27 19:48:02.915-0400 kernel smbfs_enum_dir: offset 1130 d_offset 0 d_main_cache.offset 0 for 2024-10-27 19:48:02.915-0400 kernel smbfs_fetch_new_entries: fetch offset 1130 d_offset 0 cachep->offset 0 for 2024-10-27 19:48:02.915-0400 kernel smbfs_fetch_new_entries: Main cache needs to be refilled 2024-10-27 19:48:02.915-0400 kernel smbfs_fetch_new_entries: Dir has not been modified recently 2024-10-27 19:48:02.915-0400 kernel smbfs_fetch_new_entries: Restart enum offset 1130 d_offset 0 for In other words, the failure here is occurring when you return to iterating the previous directory. That is something you could avoid/mitigate by removing/modifying t

[quote='813727022, DTS Engineer, /thread/766035?answerId=813727022#813727022'] The big difference I can think of here is that contentsOfDirectory(atPath:) only looks at the first directory level (it's shallow, not deep), which means in never recurses, which significantly changes how it interacts with SMB. [/quote] Thank you very much for your detailed help. The customer agreed to run a new test app which uses FileManager.default.enumerator(at:includingPropertiesForKeys:errorHandler:) instead of recursive getattrlistbulk calls, and it loops as well. So it seems like something weird was changed in getattrlistbulk in macOS 15. Here's what they say regarding to their server model: My original server was from HP. I rebuilt it about 8-9 years ago and has nothing to do with HP, I just left the naming convention for consistency. I think the issue is likely with Windows 10 Storage Spaces. I use Storage Spaces to pool the disk space for redundancy. It’s kind of like drive mirroring. I'm somewhat happy

Thanks for all your detailed insights. I understand that the URL version of try FileManager.default.contentsOfDirectory(atPath: path).count is faster, but both should call getattrlistbulk, and since at the very beginning I mentioned that it indeed returns a reasonable file count, it would seem that... there is indeed something wrong with my code? Although you also mentioned that you don't see any obvious failure point in it. So, to clarify here, it is VERY difficult for me to directly compare our code to your code and be CERTAIN that I haven't missed something. There are multiple API layers involved and the implementation themselves are structured very differently (the lowest level API is a enumeration layer written in C). I have done a surface level comparison of how our code interact with getattrlistbulk and from that side you code looks fine. Trying to go past that level isn't really practical. I updated my feedback report FB15497909 on October 28 by uploading the sysdiagnose and other tests performed by t

I haven't had the issue since updating to macOS 15.1 and haven't got any more reports from users either, but I will update you if I do. If this happens on macOS 15.1 or later, then please file a new bug create and create a new thread or post the bug number back here (if this happens soon). One thing to be aware of here is that a system component like this has a very straightforward API surface (give URL-> get Data) with a very complex underlying implementation (multiple daemons, framework layer, sandboxing, file system issues, etc.). That dynamic means that there's a huge variety of possible failure points... of which look exactly the same at the final API layer (my bookmark doesn't work). That makes new bugs particular important because you want to make sure the issue gets investigated quickly by highlighting exactly where/how/when the failure is occur (15.1, SMB volume, on Tuesdays) and by ensuring that the investigation starts from a clean slate, not with the team which happened to be responsib

[quote='810759022, DTS Engineer, /thread/766035?answerId=810759022#810759022'] The big test I would add here is to call contentsOfDirectory(at:includingPropertiesForKeys:options:) as well or, even better, enumerate the directory with CFURLEnumeratorCreateForDirectoryURL(). Either of those should end up calling getattrlistbulk and a failure in either would be good confirmation that the problem isn't actually with your code. [/quote] Thanks for all your detailed insights. I understand that the URL version of try FileManager.default.contentsOfDirectory(atPath: path).count is faster, but both should call getattrlistbulk, and since at the very beginning I mentioned that it indeed returns a reasonable file count, it would seem that... there is indeed something wrong with my code? Although you also mentioned that you don't see any obvious failure point in it. I updated my feedback report FB15497909 on October 28 by uploading the sysdiagnose and other tests performed by the user, but haven't heard anything y

I realize that I have actually made a big mistake. When receiving the challenge on the iOS client, I forgot to Base64 decode it, which led ASAuthorizationPlatformPublicKeyCredentialProvider.createCredentialAssertionRequest() to Base64 encode it a second time. When receiving the rawClientDataJSON from the ASAuthorizationResult, in order to send the appropriate challenge back to the server, I was Base64 decoding it from the rawClientDataJSON to then send it in the expected format (removed the second Base64 encoding) to the server. This was a trick I used for the .passkeyRegistration case (as I also forgot to Base64 decode the challenge in the first place there as well), which happened to work as there is no signature produced from the clientDataHash, hence just decoding the challenge afterwards was enough. But for the .passkeyAssertion case, as the signature is produced from the clientDataHash, this obviously doesn't work anymore. When finding this previous solution, I thought this was just some Base64

[quote='768025021, jan_kala, /thread/768025, /profile/jan_kala'] I'd like to ask about the best way of getting a list of DNS servers from the system (iOS & macOS). [/quote] There isn’t a good way to do this on either platform. That’s because the concept of “a list of DNS servers” doesn’t make sense on our Apple systems. DNS servers can be scoped, based on a variety of criteria, and so there’s no one single list. On macOS you can get a lot more insight into this via System Configuration framework, but in the SC preferences and the SC dynamic store. Those APIs aren’t available on iOS. Regarding your big picture issue, if the device is on a captive network and you’re unable to communicate with your VPN server, shouldn’t you just take your tunnel down? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for sharing your results. Regarding your remaining question, I’d like to clarify your big picture goal. When your app comes back to the foreground, I see three cases: The connection is functional (A). The connection has failed via ‘natural causes’, like an asteroid strike on your data centre (B). The connection has been defuncted (C). You can already distinguish case A, because your I/O handlers are still running, so you’re asking about distinguishing between case B and C. Right? But why do you need to distinguish those? Either your app needs a connection to the server or it doesn’t. If it does need that connection, it should try to open it, and that’s true regardless of whether the connection failed due to B or C. Or am I missing something? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='812850022, fmoraes, /thread/767346?answerId=812850022#812850022, /profile/fmoraes'] The use case is finding out the list of classes that confirm to a given protocol or are subclasses of a desired class. [/quote] Right. And I consider that to be an anti-pattern on Apple platforms. You can make it work, but it has all sort of negative consequences. And that’s why I’m asking about the big picture. For example, if this were a tool that you only use during development, you should go to town! OTOH, if you plan to incorporate this into a shipping product, I’d advise you to rethink your choices. Consider this test project, which is your code wrapped into something I can run: import Foundation class BaseCounter: NSObject { } func withAllClasses(_ body: (UnsafeBufferPointer) throws -> R) rethrows -> R { var count: UInt32 = 0 let classListPtr = objc_copyClassList(&count) defer { free(UnsafeMutableRawPointer(classListPtr)) } let classListBuffer = UnsafeBufferPointer( start: classListPtr, count: