APub - odd file "crash" when "access to document file lost"

[dkenner]

I was editing a file, and stupidly I had not saved it in over an hour.  Suddenly up popped a message that I have never seen before -

"Access to document file lost:  FILENAME". Access to the document's file was lost.  This file must now be closed"

All of the work for the past hour was lost.  Is there no recovery file that could have been accessed?  I don't mind the regular APub crashes.  I just reopen the recovery file, save, and continue on.  This is annoying as work is lost.

In two years of using APub, I have never had this happen.  

(iMac, latest OS, hybrid drive, latest APub version)

[walt.farrell]

10 hours ago, dkenner said:

Is there no recovery file that could have been accessed?

Unless you've turned off the option in Preferences, your Affinity application should be saving the recovery file every 10 5 minutes.

How the recovery file operates depends on whether you've ever saved the source file at all:

1. If it was a New file, never saved, then the application should offer to recover it the next time you start the application.
2. If it was a previously existing file or a file you had Saved at least once, then the application should offer to recover it the next time you try to Open that file.

But sometimes it doesn't work.

[dkenner]

Good morning.  Then possibly this is my ignorance as the preferences are set to 300 seconds (5 minutes) and I simply do not know where this file might be hiding, as when APub came back (yes, it crashed a couple minutes later, crash file sent to Pauls) it was the older version of the file.  

For your two options, it was an existing file, previously saved several times (I started programming on batch cards, I have learned through experience [cmd+s for APub] is something done regularly and religiously.  

Specifically, this was kind of an error, as APub did not crash (this time).

>  "But sometimes it doesn't work."

Sadly, this may be the case.  But, where might the recovery file, or temporary files hide on an 2019 edition iMac?

Thank you,

Dixon

IMG_5021.heic

[walt.farrell]

1 hour ago, dkenner said:

 But, where might the recovery file, or temporary files hide on an 2019 edition iMac?

If it doesn't offer to recover the files, it is likely they are not anywhere.

But it is possible you'll find them in the "autosave" directory, which is located in the same directory as your "user" directory. The FAQ below describes where to find the "user" directory, which depends on which OS and application you're using and where you purchased the application:

If you do find them, they'll have a .autosave file extension. You would need to rename the file to have a standard .afphoto, .afdesign, or .afpub extension. Then you might be able to use File > Open. Or it might tell you that it needs the parent file, and then you're out of luck.

[dkenner]

Thank you, I'll open a terminal window and go hunting as they are not quickly showing in the file finder.  The recovery file will be somewhere, in the page file, or somewhere similar.

Dixon

[R C-R]

3 hours ago, walt.farrell said:

If you do find them, they'll have a .autosave file extension. You would need to rename the file to have a standard .afphoto, .afdesign, or .afpub extension. Then you might be able to use File > Open. Or it might tell you that it needs the parent file, and then you're out of luck.

In my experience, in the Mac versions the recovery file always needs the 'parent' file because the autosave version just saves changes made to the parent. Consequently, the autosave file size is almost always much smaller than that of the parent & the rename trick does not work.

[walt.farrell]

2 minutes ago, R C-R said:

In my experience, in the Mac versions the recovery file always needs the 'parent' file because the autosave version just saves changes made to the parent. Consequently, the autosave file size is almost always much smaller than that of the parent & the rename trick does not work.

Yes, that seems reasonable. Though assuming the parent (original) file is available still, then it might work.

Or, it may be more useful for the case where the file has never been saved, and the autosave file contains everything.

[R C-R]

Just now, walt.farrell said:

Or, it may be more useful for the case where the file has never been saved, and the autosave file contains everything.

I had not thought of that. I don't want to try to crash the app on an unsaved file to test it, but I can see how it might work, although I think in that case it should offer to restore the file without any need to look for it or change the extension. Of course if the user opted out of the restore it might be a way to 'undo' that, but I think it is more likely that the autosave file would be discarded as soon as the user opted not to restore it.

Still, every so often I notice a left over 'orphaned' autosave file from (as best as I can tell) a file that has been saved successfully so maybe it will work.