Here's the syntax for the same bookmarks from a PDF app that doesn't use PDFKit: 99 0 obj <</Type/Outlines/First 100 0 R /Last 102 0 R /Count 3>> endobj 100 0 obj <</Title(Page 1)/F 0/C[ 0 0 0]/A 96 0 R /Count 2/Parent 99 0 R /First 101 0 R /Last 101 0 R >> endobj 101 0 obj <</Title(Page 2)/F 0/C[ 0 0 0]/A 97 0 R /Count 1/Parent 100 0 R /First 102 0 R /Last 102 0 R >> endobj 102 0 obj <</Title(Page 3)/F 0/C[ 0 0 0]/A 98 0 R /Parent 101 0 R >> endobjEach cild clearly states its Parent, and each Parent has a clear First/Last statement of its children. Only one object for each bookmark. The numbers are well ordered.

Yes, I've also noticed this. A whole bunch of OpenGL games just show black or white screens. 0AD, Oolite, Armagetron, etc.

Is CUPS deprecated? The github repository was archived in March; and the last version of CUPS is dated 2022. PS. Any way to add the MacOS 27 tag to this, now we're out of beta?

No, I'm not suggesting that apps should constantly monitor fonts for changes -- that would be futile for 99.999% of the time! I was just intrigued by the behaviour, which seems to be inefficient. I'm planning to create a font management app in due course, so want as much info as possible. But it looks like there isn't any info about this.

Thanks. I've "fixed" it for the time being by copying the file to another disk; deleting it; performing a backup and then restoring it from the other disk. If it happens again, I'll follow your steps.

Clearing the font cache using atsutil has been a thing for decades. So there is clearly some sort of font cache. It seems to be a universal behaviour that any app will load the fonts it needs from the disk, and then keep them in memory. TextEdit does it, Affinity Designer does, Word does it. If apps are doing it wrong, they all are. If I change the font file on disk, that new version will be used by any app that launches. Apps already running will continue to use their old copy in memory. I could conceivably alter my font on disk before I launch every app I have, and every app would have a different version of that font. This isn't a problem that needs fixing as such: I'm just curious how it's supposed to work. If Apple is comfy with every app loading their own copy of all the font resources that they might need, rather than pointing to a single instance, then there we are. Thanks for engaging with me.

This has started happening again, with a different file, but also a large (1.78 Gb) PDF that my app opens for reading. Activity Monitor does not show the file in use by my app at the time when TM reports that it could not backup the file. Quitting my app now doesn't change the result. lsof reports nothing. The file is also locked. I have tried unlocking it, and that doesn't change anything. The file was also quarantined, so I removed that, too, also to no avail. I found a shell command to look at TM logs, and it came up with this: 2026-09-13 14:03:33 fs_snapshot_list failed: Operation not supported 2026-09-13 14:02:51 Copy failed because of a problem on destination, error: -54 2026-09-13 14:02:51 Backing up from source: '/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Ben's Mini/2026-09-13-135751/Data/Users/Ben/Documents/Music Sources/Tomkins/Tomkins Musica Deo Sacra Hi-qual.pdf', stats: l:1.78 GB p:1.78 GB c:1 2026-09-13 14:02:51 To destination: '/Volumes/TB RAID/2026-09-13-135752.inprogress/Data/Users/Ben/Documents/Music Sources/Tomkins', stats: - 2026-09-13 14:02:51 Target Volume Capacity: 4004000002048, Target Volume Free Space: 3244979351552 2026-09-13 14:02:51 Got non-OSStatus error Error Domain=com.apple.backupd.ErrorDomain Code=11 "(null)" UserInfo={MessageParameters=( 2026-09-13 14:02:51 Failed copy from volume "Data"

Sorry, just bumping this, in case anyone knows anything.

If there are unsaved changes, then the app should ask to save; and that's not happening. It doesn't seem like I'm doing anything particularly wrong, or omitting something that I ought to be doing; and it only affects a small number of files, and only occasionally. I'll keep an eye on in and see if I can investigate next time it happens. Thanks

Oh - one other possible factor: the files are Locked in the Finder, to prevent edits. They've been on a disk for over a year, unchanged, as far as I know.

Might the document's size be an issue? They tend to be over 100 Mb. It's certainly not ALL the documents that I open: only a few. It's worth saying that I've deliberately switched off the auto-save functionality (autosavesInPlace = false). Can I ask what you mean by "checking the documentEdited property"..? If I close a document with unsaved changes, it flags an alert saying that there are unsaved changes; do you want to save them. If there aren't, then the document closes gracefully. I'll see if I can trigger it again and investigate a bit. Thanks

I've been using TM since Leopard, and I have tens of documents regularly open in a variety of applications, and I've never seen this error until I started using my own app. The app's role is an Editor, as it can modify and save files. Nonetheless, TextEdit, Pages, BBEdit, and countless other apps that I use don't have this problem.

I'm just using openDocument, without overriding it. Yes, the files are on the internal boot volume (APFS). The error was flagged in the UI. TM reported that the backup hadn't completed, and in System Settings it reported the name of the file. It has done this to various files: the only connection is they are all PDFs that are or have been open in my app. Closing the app and running TM fixes the error. As usual, I can't find any relevant logs in Console.

This is the only code I have to open the PDF: override func read(from data: Data, ofType typeName: String) throws { self.thePDFDocument = PDFDocument.init(data: data) if self.thePDFDocument == nil { throw NSError(domain: NSOSStatusErrorDomain, code: unimpErr, userInfo: nil) } } I set the PDFDocument to nil when I close it.

Thanks for the link -- I would never have found that post without being led to it. Many forums have 'sticky' posts or things that new members must read; or a category for Help.