BAK file disappeared after crash

You posted three paragraphs. The first two may or may not be responding to me. The third definitely is, so I’ll address that one first.

The issue I cited, where Cubase will delete bak files if you close a project and, when prompted with “Do you want to save…?” you click, “No”, is not a “bug.” It is a disk management feature that Steinberg not only acknowledges, but defends. It is not hyperbole to say this. It came straight from the horse’s mouth: “This is how it should be.”

Now, again, I don’t know if the issue I cited is related to the OP’s issue. But it sure sounds like it.

But to clear up any confusion, let’s keep the two separate. The OP’s issue involved, best I can tell, a crash and then something about closing the project. His cited chain of events weren’t very precise and I have no way of knowing the cause.

My issue is very precise, easily replicated and has been a “feature” of Cubase from at least 7.5 to 9.5.41 (I don’t have C10).

Here are the steps to replicate it:

  1. Open a project with dat files. If you need them, make copies first.
  2. A dialog box will open saying, “A backup project exists! Do you want to open it?” Select “No.”
  3. Another box will open: “Do you want to keep the backup?” Select “Yes.”
  4. When the project opens, and this is very important, make a change to the project. Edit something or whatever.
  5. now close the project.
  6. A dialog box will open asking “Do you want to save?” Select “No.”

Poof. Your dat files will be gone. Try it.

This behavior is not disputable. Every time I get a new version of Cubase, the first thing I do is test this issue to see if they’ve finally addressed it. They never do.

And it is not hyperbole to say that someone up the food chain at Steinberg thinks this is the way this should be. I had someone up the food chain at Steinberg tell me point blank, “This is the way it should be.”

The reasoning was, if you close the project without saving, then you must not need those dat files. So to clean up disk space, we’ll delete them for you. At some point, it was determined that dat files can take up a lot of disk space, so there should be features in place to not let too many build up. This is evident in the dialog box asking if you want to keep the dat files (Step 3) or not.

This was all decided many years ago when hard drive space was much more expensive. Now, it’s just absurd.

Even worse, though, it reflects a complete cluelessness at Steinberg about what should be the most fundamental, the most critical, the most important priority over all other priorities of any DAW company: Don’t ever, ever, ever delete people’s stuff. Call it The Prime Directive.

When I turn on “Auto Backup”, I have made the decision to create a file on my hard drive. The fact that the creation of that file was automated is irrelevant. It’s still my file whether I created it manually by using the “Save As” function, or by an automated script.

So deleting dat files, which are actually, literally project files, is in violation of the prime directive. And they don’t just delete them the way we normally delete files, by putting them into the trash bin. They bypass that so they’re not even recoverable.

It is true that this behavior may never rear its head for most users. But its reared its head for me twice, where I lost important work. And it looks like it may have reared its head for the OP and others as well.

I have to say, also, that for you to come into a thread about the Autosave malfunctioning and start telling people save their work reflects a kind of cluelessness as well. And, frankly, it’s obnoxious.

Autosave is a critical feature and it should be reliable 100%. Period.

I shouldn’t even have to explain why Cubase shouldn’t be in the disk space management business. If people need to free up space, they can do it manually. Steinberg should scrap the whole backup system and start over. Or at least remove the functionality where it deletes your dat files.

Or at the very least, remove them to the Recycle bin so people can recover them without 3rd party data recovery software.

Geez. No one is disputing the facts. Make an FR, or write to the company.

I’m sorry. I thought when you called one fact “hyperbole” and you disputed another by saying this issue “isn’t widespread” when in fact, it affects every single user whether they know it or not, you were “disputing the facts”. My bad.

Now you’re not being obtuse by telling me to “write to the company” when it’s perfectly clear I’ve had extensive conversations with the company. You’re trying to be helpful, right? I got it.

You entered this thread telling people they should save their work better. Now you’re antagonizing me. Maybe you should take some time off from the forum.

Cheers

I thought it was a bug and I submitted bug report to the support team about this in 2016, and another in 2017. The gist of the response was that this is ‘as-designed’.

The take-away is basically, never hit ‘Don’t Save’ if you need .bak files to be persistent.

Admittedly I have more tolerance in terms of changing my workflow for this than than other people. I always hit save, and I always have backups going via File History or Time Machine, and I follow a generally paranoid backup ‘protocol’ where I assume everything will always go wrong. Works for me. :wink:

All that said, I’m not sure this addresses the OP’s issue…