Testing copyfile on a folder on an external volume (which takes a bit a of time) I'm running into an issue where copyfile gets to the end of the operation and then just fails. In the callback I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store it is simple enough for me to just ignore the error and return COPYFILE_SKIP but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback if I read errno it is 0. When copyfile returns it returns -1 after I return COPYFILE_QUIT (and errno is 0) so I don't know what the error is or the appropriate way to handle it. For .DS_Store just skipping seems reasonable but when copying a folder it may be appropriate to get the true failure reason. But checking the last path component of source path seems like a hack way to handle errors. If a file in the copying folder with important user data I can't just silently skip it - it isn't clear to me how I should properly proceed in a situation where I can't get the actual reason for the failure.

I use QLThumbnailGenerator to generate icons. After updating to macOS Tahoe 26.4 the folder color preference of the user is no longer respected. It just makes the icon default 'light blue.'

So I just installed the 26.4 update and unfortunately I have to debug this newly introduced issue (that may work its way into a separate thread). In my debugging steps I'm testing something related to files and I used -activateFileViewerSelectingURLs: to show the file in Finder. Now I am off the main thread. I added this line for testing purposes and I get a crash: NSWindow should only be instantiated on the main thread!' terminating due to uncaught exception of type NSException. So apparently - NSWorkspace is calling through to NSServices APIs and for some reason the system wants to present an NSError, which is a subtopic and other bug on its own because the 'Show in Finder" functionality actually WORKS but it crashed my app! #22in +[NSAlert alertWithError:] () #23in -[NSApplication(NSErrorPresentation) presentError:] () #24 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:withCarbonFocus:withSendTypes:withReturnTypes:canReleasePasteboardImmediately:] () #25 +[NSServicesMenuHandler _performServiceWithoutAlternatesFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #26 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #27 [NSWorkspace activateFileViewerSelectingURLs:] What error it is trying to present.. I have no idea. I'm not sure if I actually have a code path that calls this method off the main thread but I guess I'll have to check. This clearly goes against the documentation. NSWorkspace documentation clearly states: -activateFileViewerSelectingURLs: Discussion You can safely call this method from any thread of your app. Is this new in 26.4? I'm not sure but I just noticed. I definitely use other NSWorkspace methods off the main thread in areas of my app. Like -activateFileViewerSelectingURLs: the documentation for those other methods claims you can safely call them off the main thread. So now I'm concerned.

Sort of a continuation of - https://developer.apple.com/forums/thread/813641 I've made a great effort to get NSURL -getResourceValue:forKey: calls etc off the main thread. Great progress. So now I'm working with a file on a really slow network volume I discovered a little hang and luckily enough I'm attached to the debugger so I paused that thing. I see where I'm at. It is: NSPathControl's setURL:. It goes a little something like this: in realpath$DARWIN_EXTSN () +fileSystemRealPath () +[FSNode(SandboxChecks) canAccessURL:withAuditToken:operation:] () +FSNode(SandboxChecks) canReadFromSandboxWithAuditToken:] () LaunchServices::URLPropertyProvider::prepareLocalizedNameValue () LaunchServices::URLPropertyProvider::prepareValues () prepareValuesForBitmap () FSURLCopyResourcePropertiesForKeysInternal () CFURLCopyResourcePropertiesForKeys () -[NSURL resourceValuesForKeys:error:] () in function signature specialization <Arg[1] = Dead> of Foundation._NSFileManagerBridge.displayName(atPath: Swift.String) -> Swift.String () in displayName () -[NSPathCell _autoUpdateCellContents] () -[NSPathCell setURL:] () Could maybe, NSPathControl get the display name etc. asynchronously? and maybe just stick raw path components in as a placeholder while it is reading async? Or something like that? If I can preload the resource keys it needs I would but once the NSURL asks on the main main thread I think it will just dump the cache out, per the run loop rules.

So I'm in the middle of an asynchronous file operation. I publish an NSProgress and it displays wonderfully in Finder. But it is a folder and while the operation is in progress the user should not be allowed to enter it, modify it, etc, while the work is being done. I want to do this to protect the user from doing something silly. But Finder does not prevent the selection with the published progress. And while it would be kind of dumb to do - the user can just go about adding/removing contents to the folder while it has progress. If I remember correctly publishing an NSProgress did use to prevent the file from being selectable in Finder until either the progress finished or my app is quit (or maybe not)? But now the user is free to select, edit, modify during progress which could cause problems if the user does something unexpectedly silly. Is there a way to mark the file 'unselectable' with the published progress? Thanks in advance.

The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.

So if I create an Alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...so then my app resolves the alias using: NSURL +URLByResolvingAliasFileAtURL: What happens? The resolved URL points to a completely different folder. Well not completely different. It resolves to a folder that happens to share same last path component as the original folder...but this folder is inside the same parent folder the alias file is in. It does not resolve to the original folder I created the alias of. So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder). Couple details: My app is not sandboxed. I have permission to access the original folder in my app (but even if I didn't the alias shouldn't be mutated just by merely resolving it). Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder. Like it's just deleting the last path component of the alias and then appending the last path component of the original filename and just going with that. I hope that makes sense. I tried creating the alias myself using -bookmarkDataWithOptions: and going the other way (to Finder) but Finder must be resolving the alias using a different API because it resolves to the original location as expected.

I set the value of NSURLHasHiddenExtensionKey. I provide a textfield to rename a file and I set this flag based on whether the user has deleted or left on the path extension. So -setResourceValue:forKey:error: returns YES, does not populate the error, but does not honor the value I just set it to. I'm always setting it off the main thread on the same serial queue. Works the first time I rename the file then it just starts failing (silently). For example: NSError *setError = nil; if ([theURL setResourceValue:@(NO) forKey:NSURLHasHiddenExtensionKey error:&setError]) { [theURL removeAllCachedResourceValues]; NSNumber *freshRead = nil; NSError *getError = nil; if ([theURL getResourceValue:&freshRead forKey:NSURLHasHiddenExtensionKey error:&getError]) { if (freshRead.boolValue) { NSLog(@"it is yes when it should be NO."); } } if (getError != nil) { NSLog(@"Get error: %@",getError); } } if (setError != nil) { NSLog(@"Set error: %@",setError); } While I get that it is possible for there to be other apps setting this value at the same time as my app, doesn't really seem possible in my local environment right now. No errors log out but "it is yes when it should be NO." does log out.

So I'm reworking couple things in my app. And I noticed I had this old code that does the following: Creates a temporary directory. Writes a file in the temporary directory. After the file is written moves the file out of the temporary location and places it in its final destination. Okay so I was not creating the temporary directory using the recommended API. I was simply doing something like this: NSURL *tempDirectory = [NSURL fileURLWithPath:[NSTemporaryDirectory() stringByAppendingPathComponent:[NSProcessInfo processInfo].globallyUniqueString]]; // Create tempDirectory and write files inside it. Now I just changed the code to use the recommended API which takes the the volume of the target destination into account: -URLForDirectory:inDomain:appropriateForURL:create:error:) and I pass in NSItemReplacementDirectory and a url to appropriateForURL so the destination volume is taken into account. Now I have external storage mounted and I use the recommended approach. I discovered NSFileManager simply writes a directory right in a user facing location titled: **(A Document Being Saved By App Name) ** and the folder is not hidden. Is this intended behavior for this API? Are temporary files supposed to be user facing? I know it is good practice to clean up temporary stuff when you are done but in crashes or just forgetting to clean up will leave these behind which isn't the behavior I expect for "temporary files." Also if the user is viewing the folder in Finder they'll see these A Document Being Saved By App Name folders appear and disappear in the window as my app does this work.

The documentation says: The caching behavior of the NSURL and CFURL APIs differ. For NSURL, all cached values (not temporary values) are automatically removed after each pass through the run loop. You only need to call the removeCachedResourceValueForKey: method when you want to clear the cache within a single execution of the run loop. The CFURL functions, on the other hand, do not automatically clear cached resource values. The client has complete control over the cache lifetimes, and you must use CFURLClearResourcePropertyCacheForKey or CFURLClearResourcePropertyCache to clear cached resource values. https://developer.apple.com/documentation/foundation/nsurl/removeallcachedresourcevalues()?language=objc Is this really true? In my experience I've had to explicitly remove cached resource values via -removeAllCachedResourceValues or removeCachedResourceValueForKey: otherwise the URL contains stale values. For example on a URL that no longer exists I attempted to read NSURLIsHiddenKey and the last value was already cached. Instead of getting a NSFileNoSuchFileError I get the old cache value unless explicitly call -removeCachedResourceValueForKey: first and I'm fairly certain the value was cached on a previous run loop churn.

Running print operation on WKWebView I hit EXC_BREAKPOINT and there is all kinds of console spew that looks concerning: ERROR: The NSPrintOperation view's frame was not initialized properly before knowsPageRange: returned. (WKPrintingView) ** CGContextClipToRect: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.** WebContent[7743] networkd_settings_read_from_file Sandbox is preventing this process from reading networkd settings file at "/Library/Preferences/com.apple.networkd.plist", please add an exception. CRASHSTRING: XPC_ERROR_CONNECTION_INVALID from launchservicesd CRASHSTRING: rdar://problem/28724618 Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. WebContent[7921] The sandbox in this process does not allow access to RunningBoard. Safe to ignore all this?

I received the following crash: Thread 0 Crashed: libsystem_kernel.dylib __pthread_kill + 8 libsystem_pthread.dylib pthread_kill + 296 (pthread.c:1721) libsystem_c.dylib abort + 124 (abort.c:122) libc++abi.dylib __abort_message + 132 (abort_message.cpp:66) libc++abi.dylib demangling_terminate_handler() + 304 (cxa_default_handlers.cpp:76) libobjc.A.dylib _objc_terminate() + 156 (objc-exception.mm:496) libc++abi.dylib std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59) libc++abi.dylib __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 (cxa_exception.cpp:152) libc++abi.dylib __cxa_throw + 92 (cxa_exception.cpp:299) libobjc.A.dylib objc_exception_throw + 448 (objc-exception.mm:385) Foundation -[NSConcreteMutableAttributedString initWithString:] + 268 (NSAttributedString.m:1049) CloudDocs -[BRCloudPathComponentDisplayMetadata initWithDisplayName:suffix:url:icon:] + 180 (BRCloudPathComponentDisplayMetadata.m:75) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:]_block_invoke + 516 (BRCloudPathComponentDisplayMetadata.m:292) CloudDocs -[NSArray(BRAdditions) br_transform:keepNull:] + 228 (NSArray+BRAdditions.m:20) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:] + 76 (BRCloudPathComponentDisplayMetadata.m:276) AppKit -[NSPathCell _autoUpdateCellContents] + 2080 (NSPathCell.m:442) AppKit -[NSPathCell setURL:] + 76 (NSPathCell.m:599) AppKit -[NSPathControl setURL:] + 64 (NSPathControl.m:366) I tried reproducing on my end by passing various URLs in iCloud Drive to an NSPathControl, file reference urls, attempting to evict a URL from iCloud Drive then settings the URL property without luck. Setting the URL to nil does not crash (the property is nullable). I have no idea how to trigger that code path. Anyone else run into this and have a workaround?

Appkit starting logging these warnings in macOS 26.1 about my app's MainMenu. **Internal inconsistency in menus - menu <NSMenu: 0xb91b2ff80> Title: AppName Supermenu: 0xb91a50b40 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: () believes it has [<NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp:] 0xb91a50b40> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu ** I don't what that means. The supermenu is the menu that represents the menu used for my app's menu bar (as described by NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp Everything seems to work fine but log looks scary. Please don't throw!

I try saving the value of NSURLVolumeURLKey when creating a bookmark. When resolving the bookmark later I pass the bookmark data to +resourceValuesForKeys:fromBookmarkData: but always pull out "file:///" which is wrong. In contrast the value for NSURLVolumeURLForRemountingKey is properly saved and restored using the same method.

I noticed that I cannot even tell that an NSBox is being used on macOS Tahoe when the system is in light mode. The 'box' background can't be seen so it makes it appear that the subviews in the box aren't positioned correctly (because they are inset from the subview outside the box). There is no visual indicator that that subviews inside this box are grouped together because well, you can't see the box at all. In Interface Builder the box looks fine at Design Time in "Light Mode". In Dark Mode the box looks fine at design time and at run time. Just figured I'd throw that out there.