SketchUp Pro 2019 = Let's talk about Saving

[john_drivenupthewall]

@gary_brian

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

[audiobrad]

@mchandler

Purging auto-save files on reboot/crash is a bug (on Mac) and we’re looking into a solution for the problem.

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.

[mchandler]

@audiobrad

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.

[audiobrad]

Another link to my observations here:

@audiobrad

OK, I’ve made some progress and have some new information to report that may be helpful to some Mac users. First of all, I restarted my Mac and ran disk utility. I’m now getting autosaves in the RecoveredFiles folder (yay!) BTW, the terminal command you suggested only gave the last half of the directory path, but I was able to find the entire path using the Ruby Console command. The path lives in a root folder called “private” which is hidden, so neither the Finder or Spotlight could find it.

A few observations:

1. It appears that SU only autosaves a file if there is a change made. If you simply open a file with no changes, it won’t write anything there–which makes sense I guess.
2. The “Welcome To SketchUp” window does not give access to the autosaved file. I checked the timestamps and tested this–it only shows the last saved version. ***It would be very helpful if SU actually provided access to the autosave file as TheGuz indicated in his post SketchUp Pro 2019 = Let’s talk about Saving. SU should also provide a time stamp on these files in the “Welcome To SketchUp” window as well as the File/Open menu. When using Open, it displays a familiar Finder window, except the timestamp is removed from the date. Odd. So if checking the time stamp is important to you, you need to double click the file in Finder outside of SU.
3. If you close the file, the autosave is purged (as mentioned above).
4. If you want to go back to the last autosave voluntarily (which is something I do fairly often–not due to a crash), then you must navigate to the RecoveredFiles folder and open that file BEFORE closing the file of the same name in SU. Interestingly, this will give you two models open with the exact same name–so you have to know which one to close. A better approach is to drag the autosave out of the RecoveredFiles folder first (before it is purged), then close the open file in SU and then open the autosaved file.

Now that my computer is behaving, and I understand how autosave works and where it parks the file, I can make use of the autosaves for going back less than 5 minutes if I haven’t saved in a while. I find this enormously useful and hope that SU will provide a more transparent path for utilizing autosave in non-crash scenarios.

[audiobrad]

@mchandler

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

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

[colin]

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.

[endlessfix]

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.

[colin]

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.

[monospaced]

@mchandler

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

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

[mchandler]

@monospaced

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

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

[colin]

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.

[endlessfix]

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.

[john_drivenupthewall]

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

[ria.l.thompson]

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.

[audiobrad]

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.

[colin]

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.

[audiobrad]

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.

[ria.l.thompson]

@audiobrad

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.

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.

[JuJitsoup]

@pab037saks

I ended up having to redraw the model. I am so fearful of loosing another drawing I began manually saving and “Save As” to new a new file every 30 minutes in addition to my “Auto save” every 20 minutes.

Yeah, that’s the life and subconscious behaviour of all of us long term AutoCAD users. Just part of the workflow. Good practice on any and all software. Lesson is: NEVER EVER EVER rely on the autosave. Or backup for that matter. Because when you really need them they’ll 100% be corrupt or won’t be there at all.

[gary_brian]

My code writing guru office mate recommends developing a subconscious habit of hitting Command/S every few minutes as the only sure way to save yourself from losing hours of work. It is not an easy habit to develop, but apparently the only sure solution.