SketchUp Pro 2019 = Let's talk about Saving

I have seen this, yes. Not exactly reassuring nor sympathetic in any way, and all questions still remain unanswered. But thanks for pointing it out so others can see it in case they missed the tiny post.

2 Likes

OK. I am getting the picture now. On a Mac, the Autosave checked probably means nothing. I have never seen the red recovered file banner in the welcome window. The working file and the backup file only save with a manual File/Save. On all the other apps I know of Auto-save saves the working file at the period set. It would seem to me to be fair to warn users to incorporate manual file/ save or Command S into their habits every few minutes or so, or risk losing lots of work. This seems to me to be a major weakness. I do not remember this being a problem on earlier versions of SU.

if you use multiple documents, Autosave hasn’t ‘really’ worked on a mac ever…

it seems that the timer zero’s when you change models, so you could always end up with none of your days work autosaved if working with support files…

the other issue, which I think the ‘re-housing’ was attempting to address, was the number of people that opened the Autosave_mymodel.skp [ unintentionally? ] without re-naming it and when they had an issue supplied a Autosave_Autosave_Autosave_Autosave_Autosave_Autosave_mymodel.skp [ there was one last week on the forum ]…

I agree with burying the file, but not in a ‘system purged’ location and the dev’s have acknowledged this as a bug and I’m confident a new ‘User space’ location will be in the first maintenance release…

I only ever turn it on when testing issues like this one…

john

1 Like

It’s not really a Mac “bug” is it? SU chose to place auto-archives in a hidden temporary Mac folder that is designed to purge on reboot. Since SU made this change from 2018 to 2019, it seems the fault lies entirely with SU.

Yes. It’s not a Mac bug, but rather, a SketchUp bug on the Mac platform.

6 Likes

Another link to my observations here:

Thanks mchandler for the acknowledgement! Sometimes that’s what frustrated users need to hear before anything else.

1 Like

I helped someone with an unusual situation recently, where at exactly the end of doing a Pro trial, SketchUp on her Mac crashed, reopening SketchUp didn’t work, the trial was ended. Also, she had decided she was going to be ok with just the web app, and wasn’t going to get one of the Pro options. But, she had done a lot of work since the previous save.

I told her where to find the RecoveredFiles folder, and she was able to find a skp that was exactly how the model looked when the crash happened. She inserted that as a component in the web version, and was able to continue where she left off.

1 Like

I can see how this scenario could work out, because in her case the computer did not crash or restart, just a SU bugsplat. Otherwise we are learning now that if her computer had crashed or if she had happened to have shutdown and restarted since her last session, the file would have been erased.

I will test that, because I’ve had plenty of restarts, and still have some files in that folder. But, it’s not out of the question that they are more recent than my last restart.

Seems like this can be fixed pretty easily. When will the update be out?

3 Likes

We’re not able to comment on release dates or future versions’ features/fixes.

1 Like

Ok, I tested that, and you’re right about the folder being deleted on restart.

I used this article to make an Automator script, and can now sync the recovered folder to one on my desktop:

https://www.bananica.com/Geek-Stuff/Synchronize-two-folders-on-a-Mac-with-Automator-and-Rsync/

It seems to work.

3 Likes

Interesting idea Colin! Setting up a background process that copies the “autosave” recovery files into another folder on a regular time schedule could be a workaround for this bug. I’m sticking to 18 for now, but this idea might help out those like @ria.l.thompson and @audiobrad until a patch is released.

I wrote an Automator folder action, when this third first appeared, but the temp folder is renamed after a system restart so it doesn’t ‘stick’…

same issue with moving the folder to the side bar in finder…

close, but no cigar…

john

Thank you all who have tried to find a workaround around this SU 2019 failure to preserve autosaves in cases such as system crash, power outage, any situations that will involve a system reboot. I think at this point all of us who lost work have developed fantastic obsessive manual-saving habits (that will teach us!). The issue now with this situation is not so much that this mistake was provided in the 2019 version. Certainly, we all make mistakes, and for those of us who have done coding, we know all too well how this can happen.

What is not cool (and please correct me if I’m wrong here) is the sort of sneakiness of how this is being dealt with. First, the OP at the top makes it sound like, “here it is guys, our new and improved autosaving structure”, and this meant-to-be-informative text is missing the so important piece that RecoveredFiles will not exist in the above described cases of system failure. It’s been two weeks since the terse admission from Mark Chandler that this is indeed a bug, plenty of time for the OP to have been edited to include that bit. Or if that were not possible, find another way to make this more easily visible. Why bother to do that? So that the next frustrated users can get to the whole picture right away without having to sift through the clutter here.

Or why not update the Help page, if indeed RecoveredFIles was the new design? Again, a place the next frustrated users might look for answers. (Yes, I know I’m bringing this up for the third time, but until you tell me it is not important….)

Or would it be a completely crazy idea to maybe send out an email blast to all of the 2019 users and explain the current trouble, say something like “sorry for this inconvenience, but please save manually all the time until this is fixed so you don’t lose your hard work.”

Instead, the best we’ve got are curt messages like “we are not able to comment“. Is this really the way this ought to be?

Really, at this point this is not about the ones like myself who already lost their work. I really would hate, though, for more people to have to go through the sleepless night of anxiety, finding out that every possible backup I had (I really did have all kinds of decent backups) will not have saved a trace of an autosave. And more time spent running data recovery programs that also did not find anything. All ultimately resulting in missing a deadline. But that’s already in the past. It will not happen to me again (short of a power failure, but I would now have a very recent manually saved version).

So the bottom line is, again, this is not about the ones like me anymore. However, there are steps that can be taken to prevent more users from losing their work until the forbidden-to-be-talked-about future release date of the patch. Is this really so much to ask?

Peace.

4 Likes

I agree, Ria–well put. Given the OP’s title to this thread, you would think there would be more transparency with new information. SU is now aware of the issue and should be forthcoming about it and publish workarounds. I’m tired of these software companies’ fear of admitting mistakes (I’m talking to you, too, Intuit). We hear nothing from them about bugs, and tech support often seems unaware of the issue, then BOOM–out comes an update 6 months later and the version log indicates the bug fix. How does that happen? Six months denying or avoiding the issue, then suddenly it’s fixed? I think customers would be more forgiving if they’d acknowledge “known issues” more often and publish workarounds like Colin’s. Most of us understand that software development is fast-paced and increasingly we’re the beta testers. Might as well treat us like beta testers and open the lines of communication.

2 Likes

In my Automator action it asks for the folder, and with a default being the folder that was working when I made the action. Will be interesting to see where it points to after a restart. In fact, I’ll test that…

So, there were some difficulties. As the folder was deleted I thought I would point Automator at the new SKETCHUP/RecoveredFiles folder when it appeared. That meant opening SketchUp, making a change, and waiting a minute for auto save to create the folder and file. Even then Automator couldn’t find the folder, so I had to use Finder to find the folder. Then I pointed Automator at that folder, and was back in business again.

This is mainly just a proof of concept, and if it was made easier my use case would be that I’m making changes to a model, do something terrible, and want to quickly get the auto save file from before my terrible action. I would be ok with having to manually run the Automator action at that time. The re-hooking up the folder after a restart would be a hassle, but that might be possible to automate as well. Like with a recursive search through /var/folders/ for example, to find the new version of RecoveredFiles.

1 Like

Thanks for the update, Colin. SU simply needs to change this. In the meantime we all have to be extra vigilant and find our best workarounds. Since my computer rarely crashes, and the autosave appears to work if SU crashes (bug splat), my main interest is in rolling back voluntarily to the last autosave–which I can find using the Ruby Console and the command:
open "#{Sketchup.temp_dir}"/SKETCHUP/RecoveredFiles

I just have to remember to NOT close the SU file, and drag the autosave out of the temp folder before it gets purged.

Yeah, audiobrad, power to the people! We can lead the rebellion (well, a Rebellion of Two, but hey ;).

It’s too bad that this is the culture, I’ve seen lots of it myself in different places, including from the inside. One would think in a professional enterprise there’d be at least some willingness to express a concern about not impacting users negatively. If they do care (and this is me trying to stay positive here, but it’s waning), they are good at not showing it now….

It really is not okay, and it doesn’t help either side in the end. There’s more to be said, like what if the roles were reversed here… but I think I’ve said quite enough, and we’ve hit a dead end here. Maybe this ends here, maybe not… Maybe there is another way get through to the decision makers. We’ll see.

1 Like