Recover Unsaved Designs from Trial

[R C-R]

I saved many of the designs I was working on.  However, there were some that were a work in progress. I rarely turn my laptop off because I'm constantly using it. Since its a solid state, even when it dies, it keeps track of my programs that are running and what not.  I had been working some designs that day and the day before and I restarted my computer because it was getting slow.  I purposely did not save them because it had restored them every other time and it would have again if the trial didn't run out.

For the several reasons already mentioned, this is very poor practice, regardless of the app or what restore or autosave features it may have, what kind of drive you use, or whether they are works in progress or not. If you do not periodically save them to at least two independent locations, & one of them is not your startup drive, you are living dangerously, gambling that nothing will go wrong with the restore/autosave process, your computer or its drive, the file system, or anything else that would make the work unrecoverable.

 

This applies to any app & any document but it is critically important for anything work related.

[Ben]

@Edge

 

I am simply trying to understand the "procedure" you are using whereby you expected your unsaved work to be reopened (since all paths of shutting down the application should prompt you to deal with unsaved work), and asking you to describe what you do so that I can better understand it (since it is clearly not how the vast majority of our users chose to work) and so I can determine whether there is anything that can be done to mitigate for such issues for everyone.

 

Reading back through this thread, and not being party to all the conversations you've had with other people, this is the only description you have provided with regard to saving your work:

 

"I DID NOT SAVE THE FILES BECAUSE THEY AUTOMATICALLY SAVE AND RESTORE"

 

So, you'll understand why it's been quite difficult to piece together what your issue is and what might be done.

 

I would also ask you to be a little less abrasive towards other forum users who have only been trying to help you.

[Ben]

As a side note, the usage of our Trial and Beta comes with certain guidelines.

 

One of these is that we do not recommend them for commercial or important work.  Due to the nature of how we roll out updates to the Mac App Store, the 'official' version may be older that the Trial, and will always be older than the Beta (which contains newer features).

 

For very good reasons, we run separate sandboxed folders for the public version, the trial and the beta, so that potentially incompatible internal files do not cause issues between the versions.

 

Due to this, it might not always be possible to open backup files in the current public version if created in other versions.  So, while you are criticising our customer service team for their advice, the advice they gave is not completely inaccurate.  But, since they are not the people who wrote the software, it would be difficult for them to give a more informed or individual response than the blanket information they are trained give out.

 

We also do not generally give advice that involves tinkering in the applications working folder. We don't really want the average user making changes there because of problems which are almost certain to occur as a result.

 

I understand how our serialisation system works, and I have found it difficult to understand your problem from the initial description you have provided.

[R C-R]

I understand how our serialisation system works ...

I am guessing that in this context by serialisation you mean what is saved incrementally in the autosave files. Assuming that is correct, I have noticed that on my iMac running El Capitan Finder never updates the file size or Date Modified metadata for these files, regardless of the File Recovery Interval I have set in preferences. Relaunching Finder corrects this but I am wondering if the metadata not being updated normally is an indication of some kind of problem with my iMac.

 

Is this normal or something I should be concerned about?

[Ben]

File timestamps are usually only updated when a file handle is closed.  We keep the handles open with a lock for the duration that your document is open. So, while we will read and write from it continually, we only close the handle when you close your document.  The only exception to this is in response to iCloud or OS updates that require us to relinquish the file.  This only happens for your main file - and never for the recovery files.

 

We do update the timestamps on your main file for the purpose of back up system (such as cloud storage, dropbox, etc), but we don't bother with the recovery files since nothing really should require it.  The recovery file exists in the app sandbox folder, and is subject to change at any time.  We don't think it's necessary to include your sandbox folder in any auto-backup procedure you have, so timestamp changes would be unnecessary.

It's also likely that Finder won't immediately update the file size of the recovery files, unless something prompts it to do so.  Rest assured that we still write to the file at the interval you specify, if you have changes.

[R C-R]

 Rest assured that we still write to the file at the interval you specify, if you have changes.

 

Ben, thanks for the info. I knew the data was being updated properly because I had checked a few of these files with TextWranger when I noticed the file size & modified dates were not being updated in Finder. But it is still good to know there is nothing wrong with Finder on my system.  :)

 

If I understand you correctly, the autosave files will not be included by backup utilities like Time Machine, which is good -- it would be a huge waste of disk space if all those files were added to the backup drives! But that also emphasizes the critical importance of doing normal saves -- since only normally saved document files are backed up, there won't be any backed up autosaved versions to rely on.

[Ben]

TimeMachine, and other utilities, will back up whatever folders you include.  If you include your system Library directory, then that would include our transitory and recovery files.  I would hope the default settings excluded such folders, but there's nothing stopping people doing a complete system backup, which would include these folders.

 

Also, since our recovery system uses deltas, the recovery file on its own is useless without the original file that it was linked to, so there is little point in backing it up on its own.  If you have a recovery file in your 'autosave' (regretting using that name now) folder for an original file that no longer exists (either because it has been deleted, renamed or moved) we will delete that recovery file during our startup housekeeping since it can no longer be linked to the required original file. That is to prevent your folder getting littered with obsolete recovery files.

 

All said, the recovery files are only intended for exceptional circumstances, such as crashes or forced shutdown of the app or system.  Anyone closing their documents properly will never need them - they just go away quietly.

 

I would include people who leave their batteries to run flat with unsaved documents in the category of 'forced shutdown'.

[R C-R]

TimeMachine, and other utilities, will back up whatever folders you include.  If you include your system Library directory, then that would include our transitory and recovery files.  I would hope the default settings excluded such folders, but there's nothing stopping people doing a complete system backup, which would include these folders.

Time Machine allows users to exclude any folder they want, but I don't think there is any way to explicitly include folders it would not otherwise backup, other than by some hacks most users would not know about, or use even if they did.

 

Anyway, I have not excluded anything in /Library or ~/Library from my Time Machine backups so the autosave folder at ~/Library/Containers/com.seriflabs.affinitydesigner/Data/Library/Application Support is included in all my TM backups, as is the corresponding one for Photo, but in most backups, these two folders are empty.

 

I am not exactly sure why this is -- I know Time Machine's automatic hourly backups frequently have occurred while I have had Affinity documents open -- but regardless, this is yet another reason why it would be a bad idea to rely on these backup folders to restore Affinity document files that have not been saved normally.

 

I would include people who leave their batteries to run flat with unsaved documents in the category of 'forced shutdown'.

 

I was wondering if that might have something to do with how Edge managed to "recover" some of his unsaved files, but to the best of my knowledge (& according to pmset) that would only apply to data in the "hibernatefile" (usually /private/var/vm/sleepimage) that provides the "safe sleep" feature for hibernatemode = 3, & that just would restore the contents of RAM if the battery ran flat enough for the Mac to be totally shut down.

 

So even if that is somehow what Edge meant by "restore," which seems dubious, it is still a mystery how he managed to recover anything if he allowed the Affinity trial app to quit or his Mac to shutdown normally.

[Ben]

The most confusing part for me was this statement: "Since its a solid state, even when it dies, it keeps track of my programs that are running and what not."

 

​I think someone is confusing storage and system memory.  System memory is, of course, volatile. It won't survive a loss of power.

 

​I guess it will largely depend on hibernate behaviour - it would rely heavily on the accurate prediction of when the battery is about to expire.  Personally, I would never rely on hibernate coming back 100%, and I would always save my work before I put the computer to sleep.  Also, our recovery system knows nothing of system hibernate - it shouldn't need to - since the idea is to magically restore a running app as if nothing happened - so the system is not prompting the app to ensure that it made a recovery save before powering down.

[Ben]

Re TimeMachine - you are right - you have to explicitly exclude folders.  Kind of the opposite of other cloud backup systems.

 

The frequent saves tend to be done as trickle deltas anyway, so the overhead should be minimal.  I'd have to investigate further to see whether the backup is prompted by changes to timestamp or file writes. This will be difficult though as we cannot see what TimeMachine is doing internally.

[R C-R]

System memory is, of course, not solid state. It won't survive a loss of power.

 

​I guess it will largely depend on hibernate behaviour - it would rely heavily on the accurate prediction of when the battery is about to expire.  Personally, I would never rely on hibernate coming back 100%, and I would always save my work before I put the computer to sleep.

I think you mean system memory is volatile -- it is solid state!  B)

 

hibernatemode 3 (the default for Mac laptops) should write the hibernatefile to disk long before the battery has run down, but it still is just the contents of RAM, so it is in no way a substitute for saving files.

 

 I'd have to investigate further to see whether the backup is prompted by changes to timestamp or file writes.

From this now out of date site, I know Time Machine relies on the hidden /.fseventsd (file system events) log & logs only directory but not file changes, & if the log file is full it does a "deep transversal" instead, but I have no idea what it considers a file system event.

[Alfred]

I think you mean system memory is volatile -- it is solid state!  B)

 

Quite so, unless you're using thermionic valves (vacuum tubes)! :P

[Ben]

Yeah... what he said.  Volatile.   ;)  I can't even blame it on it being Friday.

 

I guess no one is using leech (organic) memory yet.  Less solid and more squishy.