On 7/6/19 7:44 AM, VanguardLH wrote:
Tee, oops, Tea, oops, Ti, oops, T wrote:

Windows Nein, oops Windows Ten - build 1809
Firefox 67.0.4, 64 bit

This is from Cobian Backup running Volume Shadow Copy Service (VSS).

ERR 2019-07-02 14:07 Error uploading the file
"GLOBALROOT\Device\HarddiskVolumeShadowCopy12\User s\Matt\AppData\Roaming\Mozilla\Firefox\Profiles\zi wxc4ke.default\places.sqlite":
Read timed out.

Is places.sqlite playing tricks with VSS? Are there things
VSS can't copy?

Yep, I've run across this with eM Client that uses a database. I talked
to a dev about leaving eM Client running 24x7 and running backups. He
said that VSS would create a shadow copy of the database but the delta
changes were saved elsewhere and applied later to the database. He
didn't mention another file, and if that were true I would think a
backup with both files would be sufficient to restore the message store.
I got cut short due to an appointment, but I started to wonder if the
delta changes were in memory which means they wouldn't be saved in a
backup (whether a file or image backup). He said the result of a shadow
copy of the database would result in nothing saved. I had to make sure
em Client was closed, so its database was quiescent. Alternatively, the
rep said I would have to use their own database backup utility they
include in the installation but never identify in their documentation
(called dbBackup, as I recall).

I've seen similar issues with Microsoft's SQL and other database
programs. A shadow copy was not sufficient to thoroughly back it up
which meant a restore resulted in a corrupted database. You needed to
use a backup program that specifically handled databases.

SQLite, mSQL, and SQL have a CLI (command-line interface) that let you
run commands, like SELECT. I suspect before backing up the database
that you first do a PURGE to physically erase the delete-flagged records
from the database, a COMPACT to remove the empty space, and issue a
BACKUP command to the SQL server, but that's likely a huge
simplification. SQLite lets you issue SQL commands, but I suspect you
first have to disconnect Firefox from keeping the database file open or
even updating it while open.

An SQL database lock is not the same as a file system lock attribute.

https://www.sqlite.org/lockingv3.html

If the SQLite database is small enough, and to boost its performance, it
can be in memory (hence why I wondered a shadow copy of eM Client's
database would result in saving a zero or partial database file); see:

https://www.sqlite.org/inmemorydb.html

That's why I figure the safest way to backup an SQL database is to first
make sure it is quiescent (no in use, closed after applying delta
updates). Simple databases, like PST for Outlook, can use VSS for
backing up, but SQL is a different monster.

The customer does leave Firefox running 24/7

Up time was 11 days. Maybe that was the problem. A backup
using Cobian to a local FTP server that normally takes 20
minutes was taking over 24 hours.

Well, if the web page left loaded in the web browser was dynamic, it
keeps changing its content. That's a moving target for a backup. The
locally cached copy of the document (aka web page) keeps changing.

http://kb.mozillazine.org/Places.sqlite

Since many sites use dynamic pages, or even use the meta-refresh to
repaint a page, the history keeps updating. Only if the user leave a
page loaded loaded (and for all tabs) that is completely static or an
internal about:name resource, like about:blank, will the files for the
web browser not keep changing.

Wonder what is this user's memory footprint for Firefox after leaving it
open for many days.


I am mainly concerned about the saved password and account.

Thank you for the excellent write up!

-T