Ich verwende NSFileWrapper für mein Paketdokument. Manchmal, wenn ich die Daten einer Datei im Paket anfrage, bekomme ich nil .
So stelle ich die Daten einer Datei im Paket ab:
%Vor%Diese Methode beginnt eventuell mit der Rückgabe von nil für einige Dateien (nicht alle). Leider ist es mir nicht gelungen, das Problem konsequent zu reproduzieren.
Falls es hilft, so öffne ich das Paket:
%Vor%So aktualisiere ich die Daten einer Datei im Paket:
%Vor%So speichere ich das Paket:
%Vor%Warum kann das passieren? Gibt es eine Möglichkeit, dies zu verhindern?
Die Dokumentation von regularFileContents scheint über dieses Problem zu sprechen:
Diese Methode gibt möglicherweise nil zurück, wenn der Benutzer die Datei nach Ihnen ändert Aufruf readFromURL: Optionen: error: oder initWithURL: Optionen: error: but bevor NSFileWrapper den Inhalt der Datei gelesen hat. Benutze die NSFileWrapperReadingImmediate-Leseoption, um die Wahrscheinlichkeit zu reduzieren von diesem Problem.
Aber ich verstehe nicht, was im obigen Code geändert werden muss, um diese Situation zu verhindern.
Ich habe versucht, das Dokument zu speichern, wenn regularFileContents nil zurückgibt, aber danach immer noch nil zurückgibt. So:
Es gibt nicht genug Code, um zu sehen, was wirklich vor sich geht. Die Ursache liegt jedoch darin, dass NSFileWrapper genau das ist, was der Name impliziert: ein Objekt, das eine Datei oder ein Verzeichnis darstellt. Daher kann die tatsächliche Datei oder das Verzeichnis leicht mit dem Objekt, das sich im Speicher befindet, "nicht mehr synchron" sein. Immer wenn NSFileWrapper feststellt, dass dies aufgetreten ist, gibt es für bestimmte Operationen nil zurück. Die Lösung besteht darin, NSFileWrapper Objekte kurzlebig zu machen. Erstellen und öffnen Sie sie genau dann, wenn Sie sie benötigen, und speichern und schließen Sie dann so schnell wie möglich.
Insbesondere sieht es so aus, als ob Ihr Code einen Zeiger auf einen Paketverzeichnis-Wrapper für eine lange Zeit hält und davon ausgeht, dass er immer gültig ist. Wenn sich das Verzeichnis aus irgendeinem Grund ändert, ist dies nicht der Fall. Recode, so dass Sie jedes Mal, wenn Sie es brauchen, einen neuen Paketverzeichnis-Wrapper erhalten, und das Problem sollte verschwinden.
Wenn sich die Datei auf der Festplatte ändert, erhalten Sie null (wie @Gene sagt). Sie können dies jedoch überprüfen, indem Sie matchesContentsOfURL: method which:
bestimmt anhand der beim letzten Lesen oder Schreiben der Datei gespeicherten Dateiattribute, ob sich eine Festplattenrepräsentation möglicherweise geändert hat. Wenn sich die Änderungszeit oder Zugriffsberechtigungen des Dateiwrappers von denen der Datei auf dem Datenträger unterscheiden, gibt diese Methode YES zurück. Sie können dann
verwendenreadFromURL:options:error:
Dies von Arbeiten mit File Wrappers Apple-Dokumentation.
Beachten Sie dies aus der Einleitung zu diesem Abschnitt:
Da der Zweck eines Dateiwrappers darin besteht, Dateien im Speicher abzubilden, ist er sehr lose mit jeder Festplattenrepräsentation verbunden. Ein Dateiwrapper zeichnet den Pfad zur Datenträgerdarstellung seines Inhalts nicht auf. Auf diese Weise können Sie denselben Dateiwrapper mit verschiedenen URLs speichern. Sie müssen diese URLs jedoch auch aufzeichnen, wenn Sie den Dateiwrapper später von Festplatte aktualisieren möchten.
Sie müssen also die URL in der ursprünglichen Datei speichern, wenn Sie sie erneut lesen wollen / müssen.
Interessant zu hören, was matchesContentsofURL: zurückgibt, wenn Sie keine Ergebnisse sehen.
Tags und Links macos cocoa nsfilewrapper nsdocument