PersonaBackstore.dat 90 Gigabyte

[PowerBug2.0]

Hallo,

da ich das Problem leider nicht auf Englisch sicher nicht gut genug beschreiben kann, dies auf Deutsch. 

Ich arbeite an einem umfangreichen Buch mit vielen hundert Fotos für einen Kunden. Aktuell bin ich bei rund 230 Seiten.

Die .afpub Datei hat im Moment 160 Megabyte - die eingebunden Bilder rund 1 Gigabyte. 

Mit jeder neuen Seite die ich anlege schwindet mein freier Platz auf der Systemplatte rapide - sobald ich das Dokument speichern möchte, verschwinden binnen Minuten nochmals 20 Gigabyte. Beim Exportieren als PDF noch mehr.

Beim Beenden des Publishers wird der Speicher wieder freigegeben.

Nach etwas Suchen habe ich die verursachende Datei gefunden, im Verzeichnis...

System HD -> private (unsichtbar) -> var -> folders -> v1 -> ..... -> T -> com.seriflabs.affinitypublisher

wird eine PersonaBackstore.dat angelegt, die immer größer und größer wird.

Da dies auf der System HD angelegt wird, bringt es auch nichts das Projekt auf eine größere externe HD auszulagern. Nach wenigen Minuten ist sämtlicher freier Speicher belegt und es geht nichts mehr.

Nun bin ich mit dem Projekt auf ein anderes MacBook umgezogen - das hat eine deutlich größere SSD verbaut - dort kann ich nun weiter arbeiten, aber nur da die PersonaBackstore.dat dort auf 90 Gigabyte anwachsen kann.

Das Problem ist auf beiden Systemen vorhanden - es ist also Hardware und System unabhängig (auf dem einem Sierra installiert, auf dem anderen Mojave). 

Die Installation des aff Publisher ist aus dem MacApp Store.

Vielen Dank schon jetzt, wäre wirklich super wenn es dafür eine Lösung gäbe, denn freier Speicher auf der System HD ist in der Regel knapp. 

[thomaso]

Im 'var' Ordner legt macOS temporäre Dateien ab, die, anders als 'normale' Cache Ordner, nach Programm-Ende oder Dokument-Schließen immer gelöscht werden.

Bei mir (– Affinity ist nicht via AppStore installiert –) ist die Struktur etwas anders als bei dir, ich hab keinen Odner 'v1' in 'folders' und ein Ordner namens 'com.seriflabs.affinitypublisher' liegt bei mir nur in user/Library/Caches (mit ca. 2 MB).

In var > folders > ... > T sieht es recht leer aus, die PersonaBackstore.dat hat 0 kB.
Dabei sind AfPub + AfDesigner mit mehreren Dateien seit Tagen geöffnet und werden bearbeitet und gespeichert:

Vielleicht geht bei dir etwas im System schief. Seltsam ist, dass das Problem auch auf einem weiteren MacBook auftritt.
Diese Tipps hast du vermutlich schon versucht, oder? : Neustart bzw. sicherer Neustart
https://www.macvillage.de/blog/2017/09/19/temporaere-dateien-in-privatevarfolders/

Welche macOS Versionen laufen auf den beiden Macs?

[PowerBug2.0]

Hallo thomaso,

vielen Dank erst mal. Ja, wäre möglich, dass es nur die App Store Installation betrifft - guter Hinweis.

Neustart usw. habe ich durch - da es 1:1 auf zwei so unterschiedlichen Systemen / Geräten auftritt, glaube ich nicht an ein Problem in der Installation meines Systems.

Zuerst hatte ich das Problem auf einem MacBook Air... wegen der kleinen 128GB SSD konnte ich schon immer nach ein paar Minuten Arbeit an dem Projekt nicht mehr weiterarbeiten. 

Die unsichtbare Datei wird auch beim Beenden des Publisher gelöscht - funktioniert also soweit "normal" - nur wird sie halt beim Weiterarbeiten gleich wieder angelegt und wächst rasant.

Auf dem Air ist 10.14.4 Mojave installiert. Auf dem anderen Rechner (ein älteres MBP bei dem man noch die Systemplatte einfach tauschen konnte) ist ein älteres System installiert... glaube 10.12.irgendwas. Da in dem Gerät eine 750GB SSD steckt, konnte ich dort weiterarbeiten.

Mittlerweile ist die Datei auf über 300 Seiten angewachsen, die unsichtbare Datei hatte dann irgendwann rund 100GB, wurde aber dann auch nicht mehr größer). 

Aber auch jetzt - wenn ich nur kurz die Datei öffne, eine winzige Änderung vornehme und das Buch dann als pdf exportiere, wächst diese Datei wieder auf 100GB an.

 

[thomaso]

Stimmt, ein Problem nur deines macOS scheint es nicht zu sein, da es auf zwei verschiedenen deiner Macs vorkommt.
Aber es scheint auch kein Problem zu sein, dass durch eine Affinity.app verursacht wird, sonst hätte es sicher schon weitere Beschwerden gegeben.
Deshalb liegt die Ursache womöglich nur in dieser einen Datei?

Wächst die PersonaBackstore.dat nur mit dieser bestimmten .afpub Datei so enorm – oder wächst sie mit jeder Datei + auf beiden Rechnern?

(Mir gelingt es nicht, sie auf meinem Mac über 0 kB zu bekommen, d.h. bisher habe ich keine Aktion gefunden, die diese Datei überhaupt benutzt bzw. füllt. – Weder "History" aktivieren, noch Persona-Wechseln + Arbeiten, noch .afdesign file in .afpub importieren und öffnen. – Diese .dat wird in AfDesigner und AfPublisher beim Programmstart angelegt und beim Programmende gelöscht, dazwischen passiert damit nichts auf meinem Mac. – Daher kann ich zu diesem Fehler leider nur Vermutungen anstellen.)

Vielleicht kannst du feststellen, welche deiner Aktionen beim Arbeiten die Datei wachsen lässt?

Da sie .dat heißt speichert sie eventuell Daten, die bereits woanders gespeichert wurden – oder werden sollen und nicht können. Hattest du auf einem der Rechner in einer Affinity.app jemals eine Fehlermeldung über fehlende Zugriffsrechte ?

[PowerBug2.0]

Ich muss mal austesten, ob es mit einer anderen Datei auch in diesem Umfang passiert. Dieses Projekt hat halt sehr viele eingebundene Bilddateien und bläht sich daher mehr auf als eher was textlastiges. 

Fehlermeldung bezüglich Zugriffsrechte gab es nicht. Ich habe auch von Anfang an alle Dateien die ich diesem Buch eingebunden werden sollen zusammen mit der .afpub Datei in einen Ordner gelegt. 

Die .dat Datei wächst immer wenn ich etwas ändere. Wenn ich die Datei nur öffne und nichts mache, wächst sie nicht. Bei jeder Änderung (neue Bilder einbinden, neue Seiten erstellen) wächst sie. 

Richtig enorm wächst sie wenn ich Änderungen speichern möchte (das Speichern dauert auch rund 10 Minuten) oder wenn ich es als PDF exportiere (was nun bei aktuell 328 Seiten und über 1000 Bildern rund 30 Minuten dauert).

Das das Problem nicht "gehäuft" auftaucht könnte auch daran liegen, dass wohl nicht soooo viele so ein Dokument in diesem Umfang erstellen (müssen) und so lange man ausreichend freien Speicher auf der Systemplatte hat, bemerkt man ja auch nicht zwingend was davon. 

[Pauls]

are you saving history with the file?

[PowerBug2.0]

3 minutes ago, Pauls said:

are you saving history with the file?

The .afpub File is a Photobook for a costumer.

The unvisible .dat File is automatic generated from the Affintiy Publisher App when i works on the Photobook and deleted automaticly when the AffPublisher closed. The Problem is only the size of the .dat File.

[Pauls]

RIght this file will be used to  store a memory image of the file - so on a big project it could be large. So long as the file is being deleted between sessions it is expected. I would recommend ensuring you have plenty of disk space on the drive where it is being created.

[thomaso]

> are you saving history with the file?

Hiermit war gemeint, ob du die Option aktiviert hast, den Protokollverlauf beim Speichern mit zu sichern (macht die Datei natürlich größer und erfordert mehr Arbeitsspeicher, weil u.U. auf sehr frühe Datei-Zustände zugegriffen werden soll.) Die Option ist im Datei-Menu, wenn du dort ein Häkchen hast dann melde das mal für Pauls. (und schalte es ab, wenn du es nicht verwenden musst).

Eine ähnliche Frage wäre, ob du die Datei mit "Speichern" oder mit "Speichern unter..." sicherst. Durch die zweite Variante werden unnötige Datenschnipsel aus der Datei gelöscht und die Datei wird dadurch kleiner, je nach Art der Schnipsel (= Art der Arbeitsschritte) recht deutlich kleiner als mit nur "Speichern". Zumindest gelegentlich ist das definitiv sinnvoll. Falls du es bisher nicht gemacht hast, beobachte mal den Größenunterschied dabei.

 

1 hour ago, Pauls said:

this file will be used to  store a memory image of the file

@Pauls, just curios to understand: I wonder why I detect this PersonaBackstore.dat on my mac at a different location than the OP and why with always 0 kb.
Is the use of this file somehow related to the source of the Affinity installer file?

[Pauls]

It resides in the $TMPDIR folder which may vary i guess. The use of it can depend on memory availability and also file availability. Not easy to predict when it is in use

[PowerBug2.0]

@thomaso

vielen Dank für die Hilfe

nein, die Funktion ist nicht aktiviert 

@Pauls

"Save History with Document" is not aktive 

 

@thomaso

ich benutze ganz normal "speichern"

 

 

[thomaso]

Dank fürs Feedback. Teste mal doch mal "Sichern unter ...", um zu erfahren, wie weit sich die Dateigröße reduziert und evtl. sogar das Arbeiten schneller wird.

Und: Pauls gab den Hinweis, dass diese .dat Datei u.a. bei wenig Arbeitsspeicher verwendet wird. D.h. du kannst zum Check auch mal das Programm "Aktivitätsanzeige.app" im Hintergrund geöffnet lassen und im Reiter "Speicher" im Diagramm "Speicherdruck" bzw. daneben bei "Verwendeter Swap" sehen, ob es ein relevantes RAM Problem gibt. Wenn die Grafik gelb oder rot wird oder die Swap-Größe (ausgelagerte Daten) wächst, dann lohnt es sich, mehr RAM einzubauen. Die Grafik zeigt die ca. letzten 15 Minuten an, der Swap jeweils die Summe seit Rechner-Start bzw. login.

[PowerBug2.0]

also die Systeme sind wie folgt

(1) Macbook Air i5, 128GB SDD, 4GB RAM

(2) Macbook Pro i7, 750GB SSD, 16GB RAM

Da ich aktuell beruflich unterwegs bin, habe ich im Moment nur Zugriff auf (1) - hier lässt es sich zwar aktuell noch öffnen (das Projekt liegt seit ein paar Tagen auf einer externen 1TB SSD), aber das Macbook Air friert nach wenigen Minuten ein, da der komplette freie Speicher (bis auf wenige Megabyte) von der .dat aufgezehrt wurde. Jegliche Versuche mit "speichern unter" muss ich daher um ein paar Tage verschieben, bis ich wieder auf (2) Zugriff habe.

 

Unabhängig davon bin ich gerade am überlegen ob es einen Versuch wert wäre den Speicherort mit einer Verlinkung übers Terminal auf die externe SSD zu "verlagern". 

[thomaso]

Ja, die 4GB sind etwas knapp. Details zeigt es dir die Aktivitätsmonitor.app an (Grafik grün-gelb-rot bzw. Swap)

Ob eine verlagerte .dat Datei aus dem ja eher 'geheimen' (unsichtbar!) "var" Ordner des Systems noch fürs System zugänglich ist, weiß ich nicht. Aber vielleicht lohnt es sich auch, deinen "user" Ordner zu verlagern, um Platz auf der System-Platte zu schaffen. Hier steht ganz unten etwas dazu: https://www.macwelt.de/a/mac-mit-128-gb-zehn-tipps-fuer-das-auslagern-von-daten,3440075

[PowerBug2.0]

ja, klar die 4GB sind knapp, aber auf dem anderen System (auf dem ich aber auch nur weiter arbeiten konnte, da die System SSD groß genug war/ist, dass die .dat Datei auf 100GB anwachsen konnte) sind es ja 16GB... also hat es damit wohl auch nichts zu tun

[thomaso]

Wer weiß, ob es damit zu tun hat. Pauls schrieb ja, dass schwer zu sagen ist, wann diese Datei überhaupt benutzt wird. Vielleicht sind es die "aktuell 328 Seiten und über 1000 Bildern", die das verursachen. Momentan kannst du nur das Arbeiten mit dieser Datei erleichtern, verhindern kannst du die .dat nicht, ohne zu wissen, wodurch genau sie verursacht wird.

Ich habe bei Tests festgestellt, dass die Größe einer .afpub Datei reduziert wird durch eine Verkleinerung der Bilder bzw. durch eine globale Verkleinerung des Seitenformats, ohne die Bildauflösung der Resourcen zu reduzieren. (Andere im Forum haben die Erfahrung bestätigt). Klingt etwas absurd, hängt aber eventuell mit der Auflösung der in der Datei gespeicherten Voransichten zusammen: Bei großen Seitenformaten werden Voransichten für mehr Abbildungsgröße also mit mehr Auflsöung bereit gehalten. Affinity apps gehen zumindest unerwartet/ungewohnt mit Bilddateigrößen um. – Das würde bedeuten, du könntest zum Arbeiten die Dokumentauflösung senken und erst zur Ausgabe/Export wieder erhöhen. Aber selbst das wird bei deiner Dateigröße etwas dauern.

Anscheinend ist der RAM-Bedarf von Affinity mit wachsender Bildanzahl unersättlich – so gesehen sind auch die 16 GB deines anderen Macs nicht viel.

[PowerBug2.0]

so, entschuldige, hat etwas gedauert, da ich nicht früher dazu kam

Das Buch ist nun fertig - 1250 Fotos, ingesamt rund 3GB Bilddateien.

Nun mehrere Erkenntnisse:

(1) So lange ich am Buch gearbeitet habe, lagen alle Bilddateien im gleichen Ordner wie auch die .afpub Datei

Die .afpub Datei hatte dabei am Ende 215MB.

Der Ganze Ordner 3,15 GB. (mit allen verwendeten / eingebundenen Dateien).

Die .dat Datei wuchs letztendlich z.B. beim Exportieren als PDF auf 120GB an.

 

(2) Nachdem ich alle Dateien eingebettet und nicht mehr eingebunden hatte, wuchs die .afpub Datei auf 7,51 GB (warum so viel mehr als 3,15GB muss ich auch nicht verstehen, oder?)

Beim Exportieren als PDF war nun aber die .dat Datei wesentlich kleiner.

 

Dies ermöglichte nun einen weiteren Test auf beiden Systemen - ich habe die 7,51 GB große Datei auf beide Systeme kopiert, geöffnet, nichts geändert und direkt als PDF exportiert (identische Einstellungen).

Auf dem Macbook Air mit 4GB RAM passierte folgendes:

die .dat Datei wuchs auf 25 GB 

zudem verschwanden noch weitere 5GB (keine Ahnung wo, das habe ich noch nicht herausgefunden)

 

Auf dem Macbook Pro mit 16GB RAM passierte dieses:

die .dat wurde 15 GB groß

und zudem verschwanden 21GB  (auch hier weiß ich noch nicht wo).

 

Beim Beenden des Publishers wurde auf beiden Systemen der komplette Speicher direkt wieder freigegeben.

 

Anscheinend ist Speichermanagement nicht gerade die große Stärke der aktuellen Version des AF Publishers. Die Aussicht diese Erkenntnis denen verständlich zu machen, die etwas daran ändern könnten ist aber wohl realistisch gesehen genauso chancenreich als wenn ich es mir vom Weihnachtsmann wünschen würde. 

Da wohl zu wenige Kunden mit so großen Dateien arbeiten, wird das Problem kaum auftreten und daher auch nicht ins Bewusstsein von AF vordringen können.

Das Einbetten der Dateien hat die Situation stark verbessert - damit kann man nun arbeiten, auch wenn es nicht ideal ist.

 

Vielen Dank für deine Mühe

 

 

[thomaso]

2 hours ago, PowerBug2.0 said:

(1) (...) alle Bilddateien im gleichen Ordner wie auch die .afpub Datei 

Die .afpub Datei hatte dabei am Ende 215MB.

Hast du denn noch konkret Erfahrung gemacht mit "Speichern unter..."?

2 hours ago, PowerBug2.0 said:

(2) Nachdem ich alle Dateien eingebettet und nicht mehr eingebunden hatte, wuchs die .afpub Datei auf 7,51 GB (warum so viel mehr als 3,15GB muss ich auch nicht verstehen, oder?)

Der enorme Zuwachs von über 100% kommt eventuell daher, dass sowohl die Bilddaten komplett als auch zusätzlich Layout-Vorschau-Ansichten (zB Ausschnitt, Skalierung) gespeichert werden. Über eine eventuelle Komprimierung bei beidem wurde m.W. seitens Serif bisher nichts bekannt gegeben. Da kann unesreiner nur Raten.

2 hours ago, PowerBug2.0 said:

Da wohl zu wenige Kunden mit so großen Dateien arbeiten, wird das Problem kaum auftreten und daher auch nicht ins Bewusstsein von AF vordringen können. 

Es gibt durchaus einige Threads zu Dateigrößen bzw. Arbeitsgeschwindigkeit. Besonders für native Dateien (afdesign, afpub, afphoto, PDF) ist das Speichergrößenproblem bekannt und wird sicher auch behandelt, interessanterweise betrifft es ausgerechnet mit nativen Dateien die Einbettung UND die Verlinkung. Der "Weihnachtsmann" ist momentan sicher noch zu sehr mit schwereren Bugs beschäftigt, vor allem mit den sehr oft gemeldeten Crashes.

2 hours ago, PowerBug2.0 said:

Das Einbetten der Dateien hat die Situation stark verbessert - damit kann man nun arbeiten, auch wenn es nicht ideal ist. 

Danke, interessante Info – wenn auch sehr absurd. Eine Datei, die alles enthält und dadurch sehr groß wird, würde ich in jedem Fall als schwerfälliger erwarten gegenüber einer, die sich – nur bei Bedarf – Daten aus verlinkten Dateien zieht. Wieso im verlinkten Fall eine .dat angelegt werden muss mit einem Vielfachen der Größe bleibt unklar. Das Vielfache liegt aber auch hier evtl. am Nicht-Komprimieren von Bilddaten.

[Oval]

Es war zu hoffen, dass baldigst intern hochkomprimiert gespeichert würde, aber selbst der Export als .HEIC klappt leider noch immer nicht. Immerhin wurde nach ein paar Tagen geantwortet, aber ob Serif selbst der Meinung ist, dass es sich dabei um einen Bug handelt weil der Beitrag noch nicht verschoben wurde?

[PowerBug2.0]

4 hours ago, thomaso said:

Hast du denn noch konkret Erfahrung gemacht mit "Speichern unter..."?

4 hours ago, PowerBug2.0 said:

ja, also ich hatte zuerst einmal "speichern unter" gemacht - zu dem Zeitpunkt waren die Dateien aber noch verlinkt... das hat gar nichts gebracht

nach dem direkten einbetten der Dateien, habe ich dann nochmals mit "speichern unter" gesichert

[PowerBug2.0]

die nun kleinere .dat auf dem Gerät mit mehr RAM kann man sich ja noch logisch erklären, aber warum im Gegenzug anders herum nun plötzlich so viel Speicher verschwindet ist das nächste Mysterium 

[thomaso]

Ich verstehe nicht, was du mit "Speicher verschwindet" meinst. Speicher wird belegt – oder wird frei.

Falls du die o.g. 5 GB / 21 GB meinst (die im Vgl. zu den 120 GB .dat eher wenig sind): Es gibt noch (mindestens) einen weiteren Ordner mit temp Dateien der geöffneten Dokumente:  
~/Library/Application Support/Affinity Publisher/temp

[PowerBug2.0]

als die Bilder nur eingebunden waren ging der Speicher in die .dat Datei - nun wo die Bilder eingebettet sind, wird die .dat Datei nicht mehr so groß, dafür wird nun irgendwo anders noch eine weitere Datei erzeugt, die Speicher frisst... seltsamerweise eben auf dem System mit mehr RAM ein vielfaches als auf dem anderen System.... da ich noch nicht weiß wo die speicherfressende Datei ist, schrieb ich dass der Speicher"verschwindet"...    

[Frank-Hans]

Ich habe heute auch die Datei "PersonaBackstore.dat" bei mir auf dem PC entdeckt, nachdem ich mich mit ständigen Problemen beim Erstellen eines Buches gequält habe. Die Datei "PersonaBackstore.dat"hat eine Größe von 224 GB auf C. Das Exportieren des Buches hat immer eine Nacht gedauert also 6-8 Stunden 390 Seiten rund 30 GB Bildervolumen. Die PDF-Datei für den Druck ist 4,5 GB. Die Datei hat sich NICHT selbständig gelöscht beim Schleißen des Publishers. (Selbst nach einem PC Neustart war sie noch da.) Ich hatte auch häufige Systemabstürze, die ich auf das Speicherplatzproblem zurückführe. Wenn man im Taskmanager nachvollzieht (live), wie hoch die Speicher und Strombelastung ist, dann crashed das Programm, wenn der Arbeitsspeicher (32 GB RAM) voll ist und die extrem hoch Strombelastung geht. Die Datei baut sich permanent auf, wenn man arbeitet. Wenn das Buch exportiert wird nimmt die Datei am Ende des Exports die finale Größe von 224 GB an. Das ist nachvollziehbar/wiederholbar. Die Bilder sind durch Links eingebunden. Die Datenrate auf meinem D-Laufwerk, was einspringt, wenn der RAM voll ist, ist in solchen Situationen (Speichern/exportieren) bei 100 % und das über Stunden. Es kommt dann vor, dass der PC/das Programm nicht mehr reagier und wenn man die Änderungen nicht regelmäßig abgespeichert hat, alles weg ist. Ich kann mir vorstellen, dass beim Einbetten das Maximum der Datei auf die 30 GB begrenzt ist und nicht auf 224 GB anwächst, was das Arbeiten wahrscheinlich schneller macht, da alternativ sowohl der RAM am Anschlag ist, die Leistung der D-PLatte...und der PC glüht, also Stromverbrauch extrem hoch. Es wäre schön, wenn das Problem behoben wird. Wenn der Post in  English sein muss, übersetze ich das gern, falls Interesse besteht.

[thomaso]

Hi Frank-Hans,

Willkommen bei den Affinity-Foren!

In APub ist seit Version 1.8.x die Speicherverwaltung effektiver, d.h. die Größe der .afpub wächst nicht wie in v1.7.3, verlinkte (nicht eingebettete) Affinity-Resourcen belegen weniger Speicher in einer .afpub. – Doch leider führt ein Öffnen einer 1.7.3 .afpub in v.1.8.1 noch nicht zu einer Verringerung der Dateigröße; der Vorteil wirkt sich nur bei neu platzierten Bildern aus.

Kannst du bitte noch einige Infos liefern zu deiner Situation:

• Hardware-Version
• Betriebssystem-Version
• APub-Version
• Datei-Größe der .afpub
• Dokument Farbraum der .afpub
• Dokument-Farbraum der Bilder/Resourcen
• Anzahl der Bilder/Resourcen (390?)
• Dateiformat(e) der Bilder/Resourcen

Für APub 1.7.x wurden meines Wissens bisher keine zuverlässigen Maßnahmen zum Umgang innerhalb der Affinity Programme erwähnt, mit denen ein Benutzer dieses Speicher-Problem mit wenig Aufwand lösen oder vermeiden konnte. Da inzwischen die effektivere Version 1.8.1 existiert, wird Serif für Dateien, die mit v.1.7.3 erstellt wurden, schlimmstenfalls keine Lösung mehr suchen oder anbieten.