Mystery (partially) solved. I just took a sneak peak at the extended attributes of the .DS_Store file and some have a resource fork (probably the ones that were failing to copy I BET!). So appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 .DS_Stores on the NAS's with resource forks.. maybe that will help you figure out leaky compression

Also, are you sure the Finder actually copied the file (it may very well be skipping these files). Finder can copy it. I put it directly on the pasteboard in my test. In fact I can copy it too, provided I use one of the workarounds described in the other thread. Looks like this turned out to be exactly the same issue as the one described in the other thread. Interestingly .DS_Store causing problems with copying is infamous enough to have a mention on Wikipedia: .DS_Store files have been known to adversely affect copy operations. If multiple files are selected for file transfer, the copy operation will retroactively cancel all progress upon reaching a (duplicate) .DS_Store file, forcing the user to restart the copy operation from the beginning Not exactly the same issue I described, but similar! Does the file have a data fork? it has, data. I can read the filenames when I view it as 'plain text' Resource fork is less than 300 bytes but that is enough for it to cause copyfile to fail. The total file size is ~12kb. I think almost any file with a resource fork is enough to cause copyfile to choke currently due to a bug. Will get around to filing that bug soon.

FB22294400

Not really. That is, you might be able to subclass the control to get the behavior you want; however, I think the work involved would be fairly similar making your own control using our view components. True. Yea it isn't too much work. Just needed to fetch the titles and the icon images in the background. but CFURL does NOT, I briefly thought about this though I wasn't sure how path control grabs the icons (through the url or something else like NSWorkspace) and I wanted to have that in the bg too. Under normal conditions this isn't a big deal but dealing with a url on a slow network it can cause a little hitch, as I discovered!

I file FB 22340592 (space intentionally added because posting FB links seems to cause posts to be flagged until approved by a moderator, suddenly).

I see that too. Luckily, I only use the new QLThumbnailGenerator flow if the url has the "com.apple.icon.folder#S" extended attribute. I'm sure that's an "implementation detail", but still a good idea. How are you getting the icon otherwise? NSWorkspace gets the folder color right but it gets other things wrong. Quicklook thumbnailing gets the other things right, but now it gets the folder color wrong. A non-empty folder results in an icon with paper sticking out on macOS Tahoe but an empty folder doesn't have the paper sticking out. NSWorkspace seems to get everything right on 26.4 (it didn't before otherwise I would have went with it) but only when a custom SF symbol/Emoji is set as far as I can tell. And Finder has its way of being exempt from all of this, natch!

Interesting. I didn't realize that. However, it doesn't seem to always work. Yea it doesn't always work. I have a fairly solid hack workaround in place to make it work in my app, which was a bit tedious to put together. There are a few rules I discovered through trial and error. Checking for "new custom icon" not "tahoe' custom icon etc. And a few other tricks for dealing with some other issues. I was a bit proud of myself. I discovered a few folder locations where Finder got the icons wrong but my app got it right. Wasn't meant to last though. I see. My workaround still works, except for the fact that folder colors in my app are now wrong. Kind of a big deal. Been working on this update for a while now and I'm finally close to finished..but just when I thought I was out they pull me back in. I mean I guess I could do the drawing and tinting, etc. myself but really that's like another day at least. Then testing. Sorry I'm not vibing yet with the rest of them. Guess I have to decide whether to go down that road or stick my fingers in the dike and pray they don't take like 6 months to fix it. But all is not bad in the world of QL. The Quicklook slow loading of thumbnails for app icons, seems to be fixed. Before those would take like 30 seconds. If I could trade bugs I'd take that one back! Folder color is more important!

I did file FB 22349771 (space intentionally added to avoid moderation flag).

If you pass a string containing slashes where developers intentionally appended multiple components at once (e.g., [baseURL URLByAppendingPathComponent:@"Dir/Subdir/file.txt"]). Interesting. I did not realize this was intended. I would prefer an explicit -urlByAppendingPathComponents:(NSArray<NSString*>*) method for that use case. What is your concern about the API? I actually find that this API accepting this syntax /../../../ to walk parent directories rather terrifying. As many path components as you want? While that syntax has its uses I think it is extremely rare for developers to use -URLByAppendingPathComponent: intentionally in that way with that purpose in mind. The name of the method implies one I think? And you are most often trying to go forward not backward when you use this API. Tell Xcode where my headers are use of @".." okay fine but most apps don't do that. IMO that should probably be split into a different API that clearly describes the purpose. To walk back parent directories the more sane thing to do, in most apps I think is to use URLByDeletingLastPathComponent instead. If it isn't considered a 'security issue' on its own it at least looks like the seed of one.

If an app assumes it's appending only one path component on a directory it owns (like inside a package), it may think it is safe, but it can be tricked into overwriting files at unexpected file system locations.

Still running into this regularly. I think it may have something to do with using NSStatusBarButton. Is your app using NSStatusBarButton by any chance? Might be related to the timing of when I set the button's image. Really AutoLay is being overly aggressive IMO. I have another window in my app (besides what's created with from status bar button. And in the initializer are started returning nil (so only the status bar button would be created). And I still hit _NSDetectedLayoutRecursion. I don't think I have any other window created at this time but maybe I do.. I'll have to look deeper... think it has something to do with that button, though.

Still in 26.4. It goes beep beep beep, like the horn on the bus!

Thanks for sharing! They do the same thing in the Navigator now too I just noticed. I think the transition between a segmented control and a pop up button here is a little weird but overall not as bad as I initially thought. I'll just widen the navigator/inspector as needed.

Looks like Apple or maybe another app on my system decided to remap the file extension to a different UTI, I'll have to dig further to find out. Whoever is responsible doesn't own the type (I don't own it either but I'm also not trying to hijack the file extension). in any case NSDocument/NSDocumentController doesn't appear to be responsible and is in the clear.

OTOH, if you don’t set that flag then you’re telling the system that you don’t care about the state destination in the error case. The system is free to choose whatever writing techniques that it finds convenient. From the perspective of an app developer, it certainly is interesting for a save operation to fail with NSFileWriteFileExistsError while simultaneously deleting the existing file because the system finds it convenient! If you're going to chuck the file anyway is there really a point of failing after that? In any case this was a breaking change (it definitely wasn't always this way) and wasn't documented (as far as I know). But I guess my thread here helps serve that purpose and I was just "lucky" before. you’re writing to a temporary file Given how it works now, if you don't 100% know you own the path you have no choice but to write a temp since if an error occurs the system reserves the right to remove existing files at its convenience. That behavior probably should be documented IMO.