NSDocument speichert Datei mit falschem fileType

MyMattes · 2. April 2026, 10:55

Moin!

Ich habe gerade ein Problem in Apple Developer Forum beschrieben, welches ich auch hier zum Besten geben möchte: Ich habe zwar eine Lösung, die es vermeidet, aber die eigentliche Ursache ist mir unklar und vielleicht ist Euch schon einmal ähnliches begegnet:

Meine Dokumenten-basierte App unterstützt mehrere Dateiformate zum Schreiben. Wenn ein Benutzer eine Datei im Format A öffnet und im Format B speichert, wird von meiner NSDocument-Klasse bei Aufruf von saveToURL:ofType:forSaveOperation:completionHandler: der fileType A übergeben. Dies führt dazu, dass App-Kit beim Erweitern der Sandbox Unsinn macht und die nächste Schreiboperation der Datei mit der Erweiterung B fehlschlägt. Wohlgemerkt erst, wenn ich versuche, die zweite Datei erneut zu überschreiben - z. B. nach einer Änderung.

Auf der Xcode-Console sieht das (mit ein paar Logzeilen des vorher erfolgreichen Speicherns) so aus:

Quellcode

-[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 521] typeName: com.janome.jef
-[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 523] targetTypeUTI: com.tajima.dst
NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for /Users/matthias/Desktop/Ohne Titel.jef because: Error Domain=NSPOSIXErrorDomain Code=3 "No such process"
-[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/matthias/Desktop/Ohne%20Titel.dst, newURL: file:///Users/matthias/Desktop/Ohne%20Titel.jef

Leider kann ich diese Situation mit dem aktuellen Xcode-Template für dokument-basierte Apps nicht nachstellen, aber dessen Implementierung weicht auch ziemlich von meiner >15 Jahre alten App ab. Da ich eine (Übergangs-) Lösung habe, investiere ich nicht die Zeit, eine angepasste Beispiel-App zu bauen - zumal mein Vertrauen auf Bug-Bearbeitung seitens Apple in der letzten Zeit gesunken ist: Da ist von mir noch einiges offen.

Aber wenn Ihr solche Effekte kennt oder einfach eine gute Idee habt: Her damit

Mattes

tempelmann · 3. April 2026, 11:42

Ich habe auch eine App mit mehreren Typen und mußte da ein paar "tiefere" ObjC-Methoden überschreiben, damit das klappte, wie ich es wollte.
Aber dein spezielles Problem kenne ich nicht, evtl. auch deswegen, weil ich da keine Sandbox verwende.

Aber wenn du die Zeit hast, finde doch bitte heraus, ob das Problem nur bei der Sandbox auftritt - wenn nicht, kann ich mal in meinen Code schauen und dir evtl. weiterhelfen.

MyMattes · 3. April 2026, 12:21

tempelmann schrieb:

Aber wenn du die Zeit hast, finde doch bitte heraus, ob das Problem nur bei der Sandbox auftritt - wenn nicht, kann ich mal in meinen Code schauen und dir evtl. weiterhelfen.

Danke für Dein Angebot!

Ich habe eben einmal Sandboxing und Hardened Runtime aus den "Signing & Capabilities" entfernt (die Entitlements sind auch weg). Der Fehler bleibt wie oben beschreiben, was komisch ist: Ich setze in meinem Code (jetzt) keinen expliziten NSFileCoordinator ein und trotzdem bemängelt er eine fehlende Sandbox-Extension - die es ja gar nicht geben sollte.

Ich vermute, ich mach jetzt beim Testen einen Fehler...

Über einen Tipp, welche Methoden Du wie anpacken musstest, würde ich mich freuen: In der NSDocument-Klasse fallen mir nur diese ein, die irgendwas mit Lesen / Schreiben zu tun haben - natürlich gibt es dort viel mehr bzgl. State Restoration etc.

readFromURL:ofType:error:
saveToURL:ofType:forSaveOperation:completionHandler: (weil ich vor'm Schreiben noch ein paar Checks machen will, z. B. IAP)
writeToURL:ofType:error:

Den falschen fileType habe ich am Anfang von "saveToURL" protokolliert, zu einem Zeitpunkt, an dem ich keine (bewusste) Manipulation vorgenommen habe.

Frohe Ostern, Mattes

Edit: Gerade ein kurzer Gedankenblitz: Ich vermute, das immer noch aktive Sandboxing liegt daran, dass meine App auch iCloud und StoreKit 2 verwendet. Das lässt sich nun nicht "mal eben" umbauen. Aber eine Liste "Deiner" Methoden könnte trotzdem helfen

OSXDev · 4. April 2026, 14:02

MyMattes schrieb:

Moin!

Ich habe gerade ein Problem in Apple Developer Forum beschrieben, welches ich auch hier zum Besten geben möchte: Ich habe zwar eine Lösung, die es vermeidet, aber die eigentliche Ursache ist mir unklar und vielleicht ist Euch schon einmal ähnliches begegnet:

Meine Dokumenten-basierte App unterstützt mehrere Dateiformate zum Schreiben. Wenn ein Benutzer eine Datei im Format A öffnet und im Format B speichert, wird von meiner NSDocument-Klasse bei Aufruf von saveToURL:ofType:forSaveOperation:completionHandler: der fileType A übergeben. Dies führt dazu, dass App-Kit beim Erweitern der Sandbox Unsinn macht und die nächste Schreiboperation der Datei mit der Erweiterung B fehlschlägt. Wohlgemerkt erst, wenn ich versuche, die zweite Datei erneut zu überschreiben - z. B. nach einer Änderung.

...

Mattes

Hallo,

also wir hatten ein ähnlich gelagertes Problem. Bei uns lag es daran, dass wir nicht den korrekten UTType für die Ziel-Datei an die Klasse übergaben und somit fälschlicherweise das Format der Source- und Target-Datei nicht stimmig war.

Dies hat immer dann Fehlermeldungen produziert, wenn die Zieldatei bereits existiert hat. Wurde diese zuvor gelöscht, erhielten wir nur eine Warnung. :rolleyes:

Vielleicht hilft dieser Ansatz Dir.

MyMattes · 4. April 2026, 18:45

Danke, @OSXDev!

Bei mir ist einfach viel „blackbox“ aus den Apple-Klassen. „saveToURL:…“ wird durch die Standard-Funktion beim Speichern aufgerufen, ich habe davor keine Eingriff - und dort ist der fileType schon falsch.

Ich vermute irgendwas in den UTIs in der info.plist, bin aber trotz Vergleichen noch über nix gestolpert. Durch mein „Hotfix“ ist es nicht so tragisch, aber ich befürchte einfach eine Leiche im Keller, die mich irgendwann einholt.

Es wird weiter geforscht