Search the Community

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.

Currently I am working on a family photo album that has up till now 60 of the 84 pages with images with an average of about 3-4 pictures per page. The image placement policy is set to prefered linked and the images are less then 2MB per piece. After opening the file the performance menu of Windows shows that the internal RAM is filled up to its maximum and a bit later the C:-drive start to goes 100%. This process take a up to 15-20 minutes for the current file and I this takes longer evey tiem I open the file. The C:-drive is 128 GB and normally has about 20Gb of free space. Affinity Publisher is installed on this drive while the Publisher file and the photos are stored on my 1TB D:-drive. Both are SSD's. I noticed that during editing the 100% for the C:-drive happens from time to time and this is related to the Recovey File Interval. It writes to the file C:\Users\Gebruiker\AppData\Local\Temp\PersonaBackstore.dat. This file is now about 22,5 GB and is written at the moment I opened the file. When Publisher is closed the file will be deleted and there is again spaced free om the C:-drive. Now I have 17 MB of free space left. Before I started this post I openened the file Publisher is still readind and writting to the already full disk. What is going on?

Since you seem to encounter space problems here, since your C drive is pretty full and Publisher will create in your case a very huge PersonaBackstore.dat backup file, you might want to create the "Temp" directory on another drive (D or what you have physically there, which then hopefully has much more free space left) and symlink that to C:\Users\Gebruiker\AppData\Local\. - So that C:\Users\Gebruiker\AppData\Local\Temp\ is symbolic link to a physical D:\Temp directory or the like. To see how to deal with symlinks under Windows see ... The complete Guide to Creating Symbolic Links (aka Symlinks) on Windows How to take advantage of symbolic links in Windows 10 ... and so on ...

Not necessarily the swap, rather any temporary but extremely large file(s). For instance I still have one report in mind which had on mac a 90GB (!) temp file in private/var/folders/.../.../Affinity Publisher/PersonaBackstore.dat It also occurred similarly on Windows. According to Sean P (Serif) it may be caused by large image data, whereas his response was related to Windows and a deactivatable 'Parallel Processing' (which might not be a relevant info for mac) https://forum.affinity.serif.com/index.php?/search/&q=PersonaBackstore.dat Before you dive into this (possibly without any benefit) you better first check if any massively reduced disk space happens at all in your situation.

damned, same thing popup again Hdd 100% but while composing panorama. i don't know what is personabackstore.dat ?? but it is written by system and photo ..???

I remember such an unexpected enormous use of system disk space was reported before – unfortunately I can not remember to have read any successful solution to avoid this, it rather appeared as an issue which still needed investigation. Right now I found only one thread with two similar situations but note that both are using a large total amount of resource file sizes and/or report a large .afpub file size (different to your 2,9 MB). [ In previous Affinity app versions (1.7.x) were issues reported for .afpub file size with linked native Affinity file types (.afdesigner and .aphoto), this issue got resolved with an earlier 1.8.x version, whereas files created in an 1.7.x version still may show the issue if opened in 1.8.x. ] Maybe it can help to limit a reason for your issue if you detect where the memory is going to, means in what file/folder it gets written to cause your massive reduction of free disk space. Usually the macOS search tools make it difficult to search for such items but with "FindAnyFile.app" or "Whatsize.app" you can easier search for large sizes stored at any place within system folders. (In "FindAnyFile" press the option key when clicking the search button to force a search as root or sudo). Alternatively to a search for size you could search for a file named "PersonaBackstore.dat", the issue in the thread I mentioned above. It is stored in your hidden "private" folder (this is not in your user folder) and there within folders with 'cryptic' names, which may vary on different computers. This file was reported as culprit in this 2019 thread for an 1.7.x version of APub. by the OP user "PowerBug2.0": 90 GB in macOS, and on 02 March 2020 by the user "Frank-Hans": 224 GB in Windows – though it did not became clear why these users got that 'waste' of disk space while others didn't. I currently wouldn't mind these application package sizes, it is not related to your bigger issue of 'disappearing' disk space. Note that apps with more than 1 GB can be common, e.g. iMovie 1,6 GB, Lightroom 2,25 GB, Cinema4D 13 GB. In particular the size of the latter also points out that it plays a role where-to the app resources are stored: the app file itself can appear small if its developers make more use of system folders as e.g. Application Support and others.

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.

Again no issue to me with your .afpub, the sliders slight like a charm. Get beautiful colors ;•) Anyway, I wouldn't expect UI behavior issues being influenced or caused by document content, since UI settings may be but UI behavior isn't document related. Did you do this reset, with all checkboxes ticked? If yes, I know of 4 locations with Affinity app data: • In your user folder: ~/Library/Application Support/Affinity Publisher ~/Library/Preferences/com.seriflabs.affinitypublisher.plist ~/Library/Caches/com.seriflabs.affinitypublisher • In a 'hidden' directory on your mac: /private/var/folders/sc/t7vpbgl15nd3417_gpz532fc0000gn/T/Affinity Publisher/PersonaBackstore.dat (whereas the grey part might vary since these folders get created by macOS) Next options: • Try using Affinity as another user on this mac. If it works, the culprit is in your user folder. • Uninstall APub, not just by deleting the app but rather with e.g. the AppCleaner.app which searches for related system files and presents them in a list before deletion.

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?

See related to this MacOS VM system theme ... Problems from insufficient RAM and free hard disk space How to free up a swap space manually without restart? Swap Files: What They Are, Where They’re Located, and More ... etc. (do a web search) In case of Affinity apps and huge temp file size problems etc. see instead ... C-drive filled 100% by Publsiher file; PersonaBackstore.dat Scratch disk ... etc. (do a forum search)

I have a file at 400 DPI, 169 x 50 inches. The file size is a little over 2 GB. When I try to apply a zoom blur at over 1000 px over a pixel layer with perlin noise on it and nothing else, a temporary file is created in C:\Users\User\AppData\Local\Temp\Affinity\Photo\1.0 titled "PersonaBackstore.dat" as it's applying the zoom blur filter, the file size keeps increasing very fast until my drive reaches capacity, the file stopped for me at over 90 GIGABYTES (my current capacity). Is this normal? There's no way this is efficient code if the whole document is 2 gigabytes. Is this a deadly bug? or is this normal for this big of a canvas/DPI when using the zoom blur filter? There is nothing inside my document but one pixel layer and Perlin noise applied, anyone should be able to replicate this problem if it's a bug in the code.

Here's the file if anyone wants to recreate it themselves. I wish we could at the very least choose which Drive stores the PersonaBackstore.dat Sunbeam.rar

Since this afternoon, Publisher on my Mac has become super slow. Files that opened in seconds in the morning now take over 8 minutes to open. I have made no changes to the file. Even scrolling through pages or clicking on menus is super laggy, sometimes take as much as 10 seconds for things to appear. Worse still, a file called PersonaBackstore.dat has appeared in /private/var/folders/ft/vkmjt26n273b2rf21tg10_180000gn/T/Affinity Publisher/ It is currently 61.39 GB and growing. What should I do? Should I uninstall and reinstall publisher? Set up: Publisher: 1.8.3 Mac OS: 10.14.6

Dear Affinity Team. Praise: Two years ago I purchased Affinity Designer and immediately found great pleasure using it. It worked nice and fast and even worked reasonably fine on my old Surface Pro 4 with 4 GB of RAM. Version 1.6 continued in this fashion and added more nice features to it. Thus, when Publisher was announced I was excited and also bought it right after the final version was released. Rant: Unfortunately, version 1.7 made things worse for Designer and also in Publisher I encountered many problems so far. First, in Designer performance dropped drastically in 1.7. Moving elements around, editing text, panning—everything felt slower and more jagging than before. Scrolling throught fonts causes even the whole application to lag. Even just writing text in a textbox has a noticable delay. In Publisher, I had problems like copying an element causing the system to freeze for a few seconds because the clipboard of Windows was running with 100 % CPU load. While this seems to be resolved now, I encounter other problems and annoyances almost every time I am using it (which is not so often so far, but will probably also stay like that if things are not changing). Problem: After this kind of rant, I will describe a new problem I encountered yesterday that prevents me from using Publisher: Linking Publisher files within another Publisher file causes a memory leak that fills up the RAM in a rate of around 100 MB/s. I tested it first at my desktop computer (Windows 10 1903, i5-3570, 8 GB RAM, GTX 970, Affinity 1.7.3.481). There Publisher peaked out at 5 GB of RAM when having the document open. First, I assumed it would be a problem of having not enough RAM, but trying it on my workstation at work (Windows 10 1809, i7-8850H, 32 GB RAM, Quadro P2000, Affinity 1.7.3.481), it just went further until I stopped it when using 17 GB of RAM. At my desktop computer, Affinity Publisher also created a temporary file "PersonaBackstore.dat", that was already 12 GB when I stopped it. Sorry, but this is just ridiculous. The applications was in Beta for many months and was released several months ago and already updated several times. How can such things not be tested? Description: The structure of my files were the following: Document A links 20 JPG files (~67 MB of images in total) and the Publisher file is ~10 MB big. Document A has 20 pages. Document B then links Document A within image frames (all 20 pages). Having both Document A and B open and making a change to any of the documents and saving it causes Publisher to go haywire. RAM just fills up and attempting to save files can cause the "PersonaBackstore.dat" to inflate as well. I assume there is some kind of memory leak problem or looping (although Document A does not link any parts of Document B). I am willing to send you the original files for testing via email, not publicly in this forum. — Overall, I am quite disappointed how Designer and Publisher evolved this year. It seems software is not tested and the "performance improvements" found in the changelog do not reach the end user. While having recommended Affinity to colleagues in the past, I consider doing less so at the moment. It does not feel reliable enough anymore. I really hope that in the future these issues will be resolved and bring Designer and Publisher back to a state where I can call it well-tested and stable—because at the moment this just not the case. Best regards, maski89

Modern SSDs can handle a ton of writes, but I imagine over several years AP will kill your SSD if you do a lot of data merge jobs. The issue is not the slightly larger PDF that its supposed to be, the issue is AP writing several dozens of GB of data into PersonaBackstore.dat to make a < 10 MB file, which as I already mentioned results in AP writing 10000 times more data to disc than it should have

Can you explain what makes you think so? In my experience Affinity requires rather processor power, CPU or GPU, than much (= all available) RAM of a system. It wouldn't make sense to expect to have an amount of RAM installed according to the total amount of used files + linked resources, would it? Though there seem to be situations where even 90 GB aren't sufficient – which makes me think it's rather a matter of memory management than of memory size. https://forum.affinity.serif.com/index.php?/search/&q="personabackstore.dat"&search_and_or=and&sortby=relevancy

I did a reinstall. It was fine for an hour, but now it's back to this again. I've read about PersonaBackstore.dat. It's for storing things that there isn't room in RAM for. But all my various documents are mostly text. Also, I have 16GB of RAM and 10GB is shown as free, so I am not sure why Affinity is using PersonaBackstore.dat.

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 ?

One can monitor and audit such files (like "personabackstore.dat" or autosave files) and if those exceed some predefined size let them auto-remove. - Should be easy to do even under Windows with some on-board Powershell script.

This seems to describe the current situation, respectively known symptoms and consequences. But don't you think Serif could + should develop their proprietary document file format(s) in a more reliable way? I understand if that demands fundamentally different code and consequences for exiting documents but since these errors seem to be permanent / unsolvable it appears strange to hang on it because as longer the apps exist and get developed as more this consequences might matter or influence an increased number of existing user files. Or, with other words: should the reliability of saved user documents not have highest priority, even before speed, file sizes and the restore option in case of crashes? (aside the known memory hunger and the occasional oddities with the 'PersonaBackstore.dat') Outlook seems to use 1 proprietary database format (without suffix but not a macOS 'package') + 1 folder containing many sub- and subsubfolders and various file formats according to the different contents: Lightroom uses 1 proprietary 'catalog' file + 1 package … … containing folders with multiple nested subfolders for files in one format + 2 .db files:

In my impression there were quite a few reports of disk space issues, mostly on Windows. As a non-affected user (and on mac), I never dived deeply into these threads, but a search for "PersonaBackstore.dat" might shed more or different light on your unexpected lack of storage, which is different to the not auto-deleted .autosave files: https://forum.affinity.serif.com/index.php?/search/&q=PersonaBackstore.dat&quick=1

I create a document with 68 pages and a lot of pictures. It's a photobook. But my SSD crash with no more space... I discover the PersonaBackstore.dat file and this one is very big !!! I need to move this file to another folder. Is it possible ? Or to reduce the file size... No documentation about this file... Thanks !!!

I think I got it working now. I was able to export several EXR's now, both 16bit and 32bit in RGB and Grayscale mode. All I did was delete a 40GB file that was here: C:\Users\Derek\.affinity\Photo\2.0\temp The file I deleted was "PersonaBackstore.dat" which had somehow ballooned up to a whopping 40GB!

I've been using AP V1 for a while now to create a catalogue. It's not small (~180 pages with maybe 400 images), but not crazily large I would suppose. I recently noticed that when using AP, my C harddrive will run completely out of memory when leaving AP open for too long (not even using it, just being opened with that project). I realized that it's the somewhat known "PersonaBackstore.dat" file which keeps growing and growing. I have 16 GB RAM on board (yes, not too much, but assuming that everything in PersonaBackstore.dat should fit in RAM, I don't think it matters if I would even have 64 GB of RAM). I've read through several threads here in the forums and could not find a definitive answer. Someone wrote that it should (confusingly) help, to set all images to embed and not link. Isn't there any option to set the desired viewing quality, so AP doesn't render everything super high when editing (only could find the Bilinear vs. Nearest Neighbour setting)? Or to only render X current pages?

Ok, I'm seriously confused on how Affinity Publisher works and manages its internal stuff. Just out of curiousity, I saved my project as an .afpackage. When I open this one, I do not have the issue with the PersonaBackstore.dat file. It stays at 0 kB. Moreover, editing the project is WAY more responsive than it was before. I stored it once again as an .afpub file and the new size (so .afpub -> .afpackage -> .afpbub) reduced from around 104 MB to 8 MB. Opening the new .afpub also seemingly resolved my PersonaBackstore.dat issue. While I'm kinda happy that this seems to be a workaround, I have zero idea why and how. And why.