smb big sur

One of it's options is skipsSubdirectoryDescendants, which lets you disable recursion. But then I get a shallow enumeration. I still want to scan an entire directory hierarchy. The copyfile Unix API will let you do that but the Finder isn't using that either, which is why the Finder can do server side SMB copying, which copyfile cannot I've noticed that, which is why I've been using copyfile for a long time now myself. In terms of why the Finder isn't having issue I think you misunderstood. I said that the Finder is having the same issue.

So, let me start with the error here: ls: fts_read: Permission denied fts (File Traversal Stream) is basically the Unix/POSIX equivalent to Foundation NSDirectoryEnumerator. The details are documented in it's man page (man fts), but fts_read returns the next file system object in the iteration set. So Permission denied would mean you weren't able to read the contents fo that directory. Moving to here: The problem is that I get permission failures trying to delete certain directories. How were you deleting the directories? What actually failed, particularly in relation to the directory you're trying to list? After this happens, if I try to list the directory using Terminal on the 15.1 system, I get a strange error: Do you get the same failure if you open a new terminal window an navigate to the directory? Do you get the same failure if you unmount and remount the SMB volume? What do you see if you list the contents of the parent directory? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks for your detailed response. Flattening sounds like a good idea, although I'm a little bit reluctant to adopt it since this would likely mean that if one day I switch to FileManager.default.enumerator(at:includingPropertiesForKeys:errorHandler:) the bug would appear again (unless it has been fixed in the meantime). Nah, you can do exactly what I've described with enumerator(at:includingPropertiesForKeys:errorHandler:). One of it's options is skipsSubdirectoryDescendants, which lets you disable recursion. The user just confirmed to me that when copying the folder in the Finder, the same looping issue occurs. So I was wondering: wouldn't FileManager.default.enumerator(at:includingPropertiesForKeys:errorHandler:) (which I assume is used by the Finder) profit from using iteration instead of recursion as well? No, it's definitely not using that. If you pay attention to exactly what the Finder does when copying files and the functionality provide by NSFileManager, you'll pretty quickly realize that NSFileMana

Same issue since upgrading my machine to Sequoia. I'm following the guidelines from the Chromium browser (https://www.chromium.org/administrators/configuring-policy-for-extensions/) in order to try to set some custom policies for my web extension. I've tested on both Sequoia & Big Sur, and Sequoia seems to be the only affected version.

The lack of native Docker support makes me want to transition to Linux. I really hope Apple will add native Docker support. Colima (Homebrew / brew install colima / colima ssh / ~/.colima/default/colima.yaml / docker cli works from Mac Terminal) works but getting the shares and folders to work correctly is a real hassle. With vz the disk sharing works, with qemu the SMB shares work.

I disagree with your assessment that this is kind of how HTTP cookies work. The RFC you link is for how a server needs to interpret a cookie sent to it not how a client should implement creation of one. I think others would likely agree that this is a wart and that setting secure to false would result in the correct behavior of not setting the secure attribute on the cookie. It also make coding something simple like .secure: environment().isSecure() into another if statement that every person coming after will question why it's done this way and then eventually figure it out. The only reason I agree that this likely needs to stay the same is it's a pretty big breaking change at this point and many apps are likely working by accident as setting .secure to anything other than true makes no sense. Anyway... wasted more hours than I would like to admit on this as I was also adding a new networking library as well as adding cookies to the app so I spent a lot of time debugging the new library when it was

I’ve boiled your example down to this: @globalActor actor MyActor { static let shared = MyActor() } @MyActor protocol ProtocolMyActor { } @MyActor func make(value: String) -> any ProtocolMyActor { fatalError() } @MainActor class ViewObserver { init() async { let implementation = await make(value: Ciao) // ^ // Non-sendable type 'any ProtocolMyActor' // returned by call to global actor // 'MyActor'-isolated function cannot cross // actor boundary print(implementation) } } The issue here is that there are two isolation domains: make(value:) is isolated to your custom global actor, MyActor. ViewObserver.init() is isolated to the main actor. You’re trying to send a value (the resulting any ProtocolMyActor value) between these two domains, but that value is not sendable. There at (at least :-) two ways you might fix this: If types conforming to ProtocolMyActor must be sendable, you can make that a requirement of the protocol: @MyActor protocol ProtocolMyActor: Sendable { } If you don’t want to add that requirem

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