Sorry for the double post. But just a quick additional question. Am I better off working around the issue by retrying with the Carbon file manager or should I just skip the resource fork in the copyfile callback, then copy it over myself at the end?

I'm experiencing this issue. Copy file works locally for these files but fails when coming from a NAS. Works from Finder in both cases, as previously described above. copyfile does not seem to provide a usable error. The callback is invoked twice and I get : what == COPYFILE_COPY_XATTR stage == COPYFILE_START Then the callback is invoked a second time with: what == COPYFILE_COPY_XATTR stage == COPYFILE_FINISH In both cases my callback function returns COPYFILE_CONTINUE. Then the copyfile function returns -1, errno is not set. Not getting a usable error unfortunately forces kind of jackhammer workarounds. Have you noticed this issue for files without resource forks (but use other xattrs) or is the resource fork the main cause?

That does the thing! Thanks! And, yes, we probably should have documented all of this, so PLEASE file about this and post the bug number back here. I filed FB22260532

I tried setting the creation date to: 1946-02-14 08:34:56 +0000 right after creating the folder. but doesn't have the desired effect. Maybe I didn't convert the date correctly?

Thanks for the info! I've been split trying to finish up a different piece of my app related to this. I briefly tried to get this to work today using the old Carbon API which I must confess I'm not super familiar with (before my time) but didn't have any success. Before I posted this thread I tried what looked like the most straightforward way to accomplish this: [fileManager createDirectoryAtURL:someURL withIntermediateDirectories:NO attributes:@{NSFileBusy:@(YES)} error:&error]; But no luck.

Thanks a lot for explaining that. It's good to know that I can do this but I'm still hesitant to use it given the 'strongly discouraged' language in the documentation. Does the 'strongly discouraged' stuff only apply to clonefile function or should I avoid 'cloning' directories in general with the copyfile function?

I just found that Quinn wrote about this a bit here: https://developer.apple.com/forums/thread/784446 I'm still unsure why the man page for one function directs you to use another function - but that man page says cloning directories is unsupported so I'm still a bit confused about the recommendation. Is cloning directories unsupported or strongly discouraged? Basically I have to move off NSFileManager because it doesn't provide progress and it doesn't support cancelling. But I'd like to clone when possible for speed and to save the user disk space.

Thanks for all the information! The other problem here is that you're assuming the APIs involved here operate on paths... when they don't. Perhaps I didn't explain myself well. I wasn't making assumptions about how the the APIs operate - the only thing I was claiming (well trying to) was that paths provide the concept of file location and in certain contexts that concept matters to GUI apps (with the NSBrowser example being an obvious one). The current API for file reference urls that I'm aware of don't try to solve that problem in any way. Note that this INCLUDES FSEvents. [...] If the directory you're monitoring moves... then FSEventStreamCreate will happily continue sending you events about that directory, NOT the original path location. If you want to know when the directory you're monitoring moves, then that's what "kFSEventStreamCreateFlagWatchRoot" Very interesting. Yeah I use that (watch root) With the watch root flag set it does seem to just track whatever is at the path. To test this I just put 'TestFolder' on my Desktop and started a FSEventStream on it. Then I rename 'TestFolder' to TestFolder2 I pick up the root change. If I start making changes in TestFolder2 I'm not picking up any changes. With the stream still open, I create a new folder 'TestFolder' - and the opened stream starts picks up changes on the new TestFolder (not TestFolder2) along the original path - so it does 'stick' to the path and doesn't follow the reference (I've never tried not using kFSEventStreamCreateFlagWatchRoot since I need it). then it might be worth starting a new thread that's focused on those issues. I've not had problems with FSEvents I just brought it up because if there was some pathless way to achieve what an FSEventStream provides I'd be open to exploring it. I'll be sure to open a new thread if I run into anything.

Revisiting this six years later - moving to copyfile instead of using NSFileManager. Nothing seems to have changed unfortunately. FB7656661 is still open.

Actually if I create the alias in my app using -bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error: it resolves proper. so it appears to be an issue with the way Finder makes aliases. Maybe they are using relativeToURL: parameter? Weird.

It means apps don't need to actively track the current location of their files, but can instead determine its current location whenever the user actually asks for it. What should happen if you expand a directory with four subfolders in a NSBrowser (so four columns). And the third folder moves? If an app just follows the file reference URL the UI is broken. I mean if there are/were APIs that handled this in file reference world I'm with you! The concept of file location matters to users and to a lot of apps. I hope Apple doesn't want to put apps in single file jail. Here you get that one txt document and if it moves don't worry we got you. There are other types of apps that do other things. Please don't turn macOS into iOS :)

I'm not sure what you mean here. If you want to know the current path location, then you ask the kernel to convert the reference to a path. [..] I'm not quite sure what you're thinking of here. If you're trying to display the contents of a directory hierarchy, then the process is exactly the same for paths and references. You start with the container and recursively iterate its contents, displaying whatever you find. What about changes? FSEventStreamRef reports changes on a directory. Does it work on file reference urls? I never even thought of trying. I can pick up changes on a subfolder 4 folders away from the root folder I'm watching, all using a single FSEventStreamRef. I'm not saying it isn't possible I just don't know? how can I parse a single change using current APIs in a deep tree with opaque file reference urls that don't have a concept of location without first converting to path to see what level I'm at? Sure. Why not? That's what the Carbon File Manager did. Well I'm not totally against the idea nor was I arguing that it was impossible. I'm just saying it isn't in the API today, so I need a path to create a file. As you already mentioned previously macOS is very path based. In my original sample the code does not indicate in any obvious way that I wanted to use a file reference URL but merely asking NSFileManager the 'relationship' caused a really undesirable side effect. but I suspect this is actually a new bug, possibly introduced in Swift Foundation[1] [1] Much of the Objective C "version" of Foundation is actually written in Swift now. Lord have mercy! I have another issue that may or may not be related to this in some way but I think I'm going to have to spin up a separate thread.

I did programmatically change first responder via a call to -makeFirstResponder inside my responder's -cancelOperation: I've been doing this for years no issue until Tahoe 26.3. I had a reason for doing this (to end editing). I think it was to workaround some kind of bug. Now it appears that the cancelOperation 'event' wraps back to the window and NSWindow just beeps. In the case of view that uses NSBrowser I tried changing the -makeFirstResponder: call and passed in the browser itself instead of nil but I still get a beep. It still wraps the event back to the window but that key event I think should not be in the event queue anymore. In another view that uses a table view this causes a bunch of key events to get stuck in the queue and they get sent to the window later and I get a beep beep beep. In the non-browser case just passing in that table view to makeFirstResponder: seems to fix it. IN the view that uses the browser I seem to get that beep no matter what. Just overriding -cancelOperation in NSWindow subclass and not calling super is my workaround for now.

Very interesting info! I can understand that thinking, but it's not the system’s perspective. The system’s "view" here is that the file reference is considered more "authoritative" than the path. I actually don't have a strong opinion about file reference urls vs. file path urls but from my perspective in the sample it is clear after the second call to createDirectoryAtURL:..., when that method returns, the fileReferenceURL left lingering in that untitleFour instance is pointing to to the wrong folder based on the fact that I fed that URL directly into a method to create a folder, the operation succeeded, yet there is still a chance to accidentally access a completely different folder through that very same instance going through the cached fileReferenceURL. MacOS itself is heavily still reliant on path, but fileReferenceURLs are the closest construct we have to an API that doesn't fall into this "trap". Yea. You can't even create a file without a path so there is that. File reference urls are great at certain things (put this file on the pasteboard - it'll work even if it moves) but you'd really need to introduce a slew of new APIs for developers to really be able to go 'pathless.' Would every method to create a file or folder have to take a parent (fileReferenceURL) parameter? There is a whole class of applications that display / organize files based on their file system location and file reference don't work very well with that concept. How does something like NSPathControl work in a world where there is no file paths? I guess that's the point. File reference urls describe what, but what about where? You might be able to organize a list of files in a tree and manage parent-child relationships using mostly file reference urls (NSURLParentDirectoryURLKey?) but I won't be the guy trying that in 2026!

Very interesting. Thanks a lot for the detailed responses. As I mentioned briefly in a previous post I stumbled across this commenting out some things to test out an error handling code path. As a result of the matching NSURLFileResourceIdentifierKey the wrong error message was logged. In my app's case this is basically a harmless bug because I do nothing but the behavior did spark my curiousity. In any case I will most likely be removing -getRelationship: calls from app entirely soon. I'm surprised that a fileReferenceURL would be cached in a filePathURL at all. My expectation is when calling fileReferenceURL on a file path url is to get a reference to the file at the exact file path right now if it is there (or nil) and I would have to hold the fileReferenceURL on first access to follow the file around. If caching the fileReferenceURL in the URL itself has been determined to be necessary I'm also somewhat surprised an existing fileReferenceURL isn't cleared/updated when files are manipulated via high level APIs like NSFileManager -createDirectoryAtURL:.... etc. After recreation as you mentioned if you did untitledFour.fileReferenceURL you'd be manipulating the folder in trash not the new folder you created. Based on your previous reply it sounds like it would be chalked up as an app bug since you recommend grabbing the fileReferenceURL early. But IMO it isn't obviously clear by the public interface that NSURL may return a 'cached/stale' file reference url. I'm not actually doing this and i'm glad i'm aware of this possibility. It doesn't seem so far fetched that this could be a source of a dataloss bug or something worse. In my silly example it is obvious that I'm recycling the untitledFour NSURL instance. In a real complex app where you are passing NSURLs around like hot potatoes to various objects it may not be so obvious.