Rhetorical question - Why does Quicken have to close the file to make backup?

splasher

We see all the time that users using a third party routine like One Drive or DropBox have trouble with not being able to re-open the Quicken data file after a Quicken Backup.

When I do an OSU, when there is a software upgrade available, you get a message on the OSU Summary window that "A new version of Quicken is available" along with the button to "View Update".

At this time, there is nothing new in the BACKUP folder of the Quicken data file location.

If you click on the "View Update" button, you are shown the release notes available at that time and a .QDF-backup file is created in the BACKUP folder.

There was no delay, no flashing of the screen to do a re-write, the backup file was created instantaneously without closing the file, so evidently, there were no pending writes to the file that were needed to be committed.

So, my question is, why does a File->Copy or Backup File (or CTRL+B) require closure of the file which triggers One Drive and DropBox to grab the file and making a backup prior to a potential software does not?

Tom Young

I don't have enough of a programming background to even attempt to come up with an answer.  But a "rhetorical question" is a question that you don't expect to get an answer to, so I guess that's OK.

thecreator

Hi Tom Young,

Quicken does not close Quicken when performing a Manual Backup. But you can't make any changes to Quicken, until the File is Backed up Successfully. There is a small window that pops up to confirm the File is backed up successfully.

splasher

thecreator said:

Hi Tom Young,

Quicken does not close Quicken when performing a Manual Backup. But you can't make any changes to Quicken, until the File is Backed up Successfully. There is a small window that pops up to confirm the File is backed up successfully.

You are splitting hairs.  Quicken, the program, might not close when doing a manual backup but it does close and release the data file to make the backup, otherwise One Drive/DropBox would not grab hold of the file and block Quicken from re-opening the data file.
Please don't confuse the issue with things that are not part of the discussion.

Chris_QPW

I agree with @Tom Young you stated you don't want an answer.  

But I will venture a guess (as a programmer).
By closing the file, they have ensured that everything is flushed to the database and that it isn't possible that some parallel thread in Quicken isn't doing any data writing, as such will make a consistent backup.

As for why they can make an automatic backup without closing the data file, I think you are only looking at a difference in "confidence" about what state the Quicken GUI/data file is in.

Without looking at the code there would be no way to judge if they are being overly confident on that one case or "just playing it safe" in the other cases.

Strickly, speaking they need to know two things.  That all data has been flushed to the data file, and that the isn't any operations going on in Quicken that can cause it to write to the data file.

I personally have always contended that the fact they have to close the data which releases the file lock, that they have poor control/understanding of how the inner working of Quicken work.

Chris_QPW

BTW while we are on this subject.  It is my belief that it is a total myth that having your data file in a "cloud folder" will corrupt your data file even if the user never tries to use it on another machine before it is synced.  At least to for the "cloud servers" that I have used like Dropbox and OneDrive.

The only possible way that one of these services could corrupt your data file is if they tried to merge a change from one machine into the changes of another machine.  But I'm pretty sure that these services all know not to try to merge a binary file like the Quicken data file.  It makes no sense.  Yes, one person's changes can be lost, but I don't think they would actually try a merge, which since it can't be done would result in a totally corrupted file.  But that is only if the user makes changes on the same data file on two different machines at the same time (at the same time being defined as the two data files are open at the same time, plus the time to do the sync).

On the other hand, there is definitely chances of "errors", but they don't corrupt data files.
And it all comes down to this "close" and then "open" flows that they are doing.

Quicken closes data file, cloud service opens it and locks it, Quicken can't open data file and complains in few different ways.  Like either putting up an error message that it can't access it or acting like you are a new user opening a data file.  But the bottom line here is that at no time were two programs reading (let alone writing) the Quicken data file.  It is impossible for it to be corrupted.

Instead, all you have to do is wait till the sync is done and open the data file in Quicken again.
And I will note that I have seen Quicken to Quicken operations fail in the exact same way.  Quicken doesn't even handle this 100% correct in its own processes!

There is some kind of race conditions.  I think Validate and Repair is one of them, and it makes sense.  You have it close the data file, then runs validate and repair, then that is closed, and then Quicken opens the data file again.  So, it is one that has the "best chance" to mess up if there is a race condition.