<p></p>
<p><b>@freimair</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/bisq-network/bisq/pull/4233#discussion_r481113650">p2p/src/main/java/bisq/network/p2p/storage/persistence/SplitStoreService.java</a>:</p>
<pre style='color:#555'>> +            log.error("Could not copy resourceFile {} to {}.\n{}", resourceFileName, destinationFile.getAbsolutePath(), e.getMessage());
+            e.printStackTrace();
+        }
+
+        // split
+        // - get all
+        SplitStore historicalStore = readStore(destinationFile.getName());
+        // - subtract all that is in resource files
+        store.getMap().keySet().removeAll(historicalStore.getMap().keySet());
+
+        // - create new file with leftovers
+        storage.initAndGetPersisted(store, 0);
+        storage.queueUpForSave();
+
+        return historicalStore;
+    }
</pre>
<blockquote>
<p>Why are we copying historical datastore checkpoints/splits out of resources? Because that's what the live-store-only solution we currently use does? For troubleshooting purposes? Seems unnecessary, though I may be missing something.</p>
</blockquote>
<p>the existing file storage mechanisms are all tailored to working in the working directory. Changing that would be equivalent to replacing the file storage mechanisms with something else entirely. Hence, leaving it as is (until <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="595721729" data-permission-text="Title is private" data-url="https://github.com/bisq-network/projects/issues/29" data-hovercard-type="issue" data-hovercard-url="/bisq-network/projects/issues/29/hovercard" href="https://github.com/bisq-network/projects/issues/29">bisq-network/projects#29</a>).</p>
<blockquote>
<p>I presume we keep the live store in the working directory, because we can't mutate resource files (is that even true?).</p>
</blockquote>
<p>Well, obviously, the "live store" is something that is created and maintained by the Bisq app per installation and even per (configurable) app name and path. Placing that in the resources would only allow for a single instance of the data store AND would be overwritten and therefore invalidated on every app upgrade.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/bisq/pull/4233#discussion_r481113650">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNTVL3R4HZKLMDGNV23SDTVCHANCNFSM4MY33J4A">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNV5QG2QKFFKLZAET6DSDTVCHA5CNFSM4MY33J4KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGODSL4RWQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/bisq/pull/4233#discussion_r481113650",
"url": "https://github.com/bisq-network/bisq/pull/4233#discussion_r481113650",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>