Another case of LOST DATA (open files list, recovery file?)

[Brad Brighton]

1. Open APh 1.7.1 and ensure there is 1 or more files open
2. Attempt to open APh 1.6.11 while 1.7.1 is open
   1. Get the 1.6.11 splash
   2. Get the alert that Photo is already running -- :-|
3. "OK" the alert and watch 1.6.11 go away
4. Quit 1.7.1
5. Relaunch 1.7.1
6. See an empty window

Status of any autosaves or recoveries? Unknown.

Why might this scenario happen? 

1. Comparing behavior on a given file of version over version
2. Attempting to isolate behaviors reported in the forum (which is how I triggered it, trying to help out)
3. Preserving project file compatibility in a mixed version environment
4. Preserving project file compatibility with external services
5. Accidentally launching an older version

[MEB]

Hi Brad Brighton,
You can run both the Release and a Customer Beta version simultaneously (they are independent from each other and don't share any installation files) however you can't do it with two release versions (i.e. 1.6 and 1.7) for this same reason (they share some files). Usually a regular user only has the latest version installed.

Regarding recoveries/autosaves, when you quit 1.7.1 (step 4) Affinity should have prompted you to save the changes you may have made to the opened documents. So I'm not sure how you are losing data here. Have you force quit the app?

[Brad Brighton]

Hi @MEB,

I'm curious -- did you follow the steps I outlined and did you see the same behavior? At the very least, the data loss is the list of open files. There may be more but I left it as unknown on the rest because it's not a user-visible thing the presence/absence of some of those pieces.

As to "normal users shouldn't encounter this", first, I'd point to every request to be able to reinstall 1.6 here on the forums (several) as a possible candidate for running into this. Do I think a substantial portion of the userbase will be affected? No, probably not, but think of this straightforward example: since the file format is not backward-compatible, if you have two people, one on 1.6 and one on 1.7, working on the same project, the 1.7 user will need both apps. (Again, refer back to the requests to reinstall 1.6 for some of the reasons why the 1.6 user may be staying on 1.6 and not upgrading.) Relying on users to remember to quit out of 1.7 before opening the 1.6 file in 1.6 is blaming the user for what arguably could be considered an app failure.

Please note: I'm not asking for the ability to run both simultaneously -- I understand at least some of the variety of reasons why that's disallowed. What I'm asking is that my 1.7 app state should not be impacted by the steps I outlined in the OP. Speculating, it looks like the open file list is updated only at the time it's changed (generally, a good thing) but the at-launch code updates it before the app has successfully completed restoring state. Since, in my scenario, I didn't make any changes that would force an update in 1.7, the partial launch of 1.6 wipes it out.

It's way too easy (IMO) to induce destructive conflicts accidentally and honestly, it's a little dispiriting the number of issues there are with properly maintaining application state across simple error scenarios.

Ultimately, this is less about the specific 1.6 vs 1.7 thing (that's just a symptom) and more a plea for additional developer attention to the ongoing integrity of both the content files and application state management.

 

EDIT: Oh, and to answer your specific questions (sorry!):

1. I made no changes during this process so there was no NEW data from the session for the app to ask me to save at step 4.
2. No, I did not force-quit; there was no need.

Edited July 12, 2019 by Brad Brighton
Added the answers to the specific questions asked