Hello, Thanks for your detailed explanation. ...yes, please file a bug on this and post the bug number back here. Sharing your bug number regarding this topic which I previously filed. FB21561068 https://feedbackassistant.apple.com/feedback/21561068 What's the scenario it's failing at? When determining whether the URL is in “trash” location by using API with the following steps, we are seeing a failure. Precondition: Download the attached sample project (TrashedFileURL.zip) in the feedback which I shared with you in above and build the TrashedFileURL.app from the project inside the zip folder. 1.Create a file in NSDocumentDirectory by TrashedFileURL.app. a.file:///private/var/mobile/Containers/Data/Application/{Application UUID}/Documents/{File UUID}.txt 2.Save the Bookmark of the file created in 1. in TrashedFileURL.app. 3.Delete the file by Files.app. 4.Get URL of the file from the Bookmark which is saved on TrashedFileURL.app. a.URL is referring a filepath which is inside of .Trash directory. file:///private/var/mobile/Containers/Data/Application/{Application UUID}/Documents/.Trash/{File UUID}.txt 5.When running [NSFileManager URLForDirectory:NSTrashDirectory inDomain:NSUserDomainMask appropriateForURL:url create:error:] to the URL which got in 4., it will return the following Error. Error Domain=NSCocoaErrorDomain Code=3328 "The requested operation couldn’t be completed because the feature is not supported." 6.When running [NSFileManager getRelationship:ofDirectory:NSTrashDirectory inDomain:NSUserDomainMask toItemAtURL:error:] to the URL which got in 4., it will return the following Error. Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." If you need any additional information, please let me know.

Behavior has been changed by several macOS updates. Share the details in the following. All issues have not been clear yet on macOS 15.0 beta 6(24A5320a) though. macOS 14.0 - macOS 14.3 : The drawing mechanism of NSView has changed significantly, and there is a problem that even if a partial area is specified with setNeedsDisplayInRect in an app program, the full area is always passed in drawRect. macOS 14.3 - macOS 14.4: The issue with setNeedsDisplayInRect has been corrected, and the partial area is now passed in drawRect. However, another issue occurred that the number of NSView drawRect and mouseDragged events gradually decreased when continuously performing setNeedsDisplayInRect on a partial area. macOS 14.5: Even if a partial area is specified in setNeedsDisplayInRect in an app program and drawn continuously, the system will now periodically draw the entire area. This change has eased the problem of events-decreasing which are described above. macOS 15.0 beta (24A5289h) : The number of events such as drawRect and mouseDragged in NSView has been dramatically reduced, so the regular full-area drawing by the system described above is no longer useful and is worse than in macOS 14.4. macOS 15.0 beta 4 (24A5298h) : It is back to macOS 14.5 equivalent behavior. macOS 15.0 beta 6 (24A5320a) : No change. Even on the latest macOS 15.0 beta 6 (24A5320a), there is an issue that the system periodically draws the whole area even if a partial area is specified in setNeedsDisplayInRect and drawn continuously. macOS 13 did not have such an issue.