305004 - Create a dated bookmark backup file periodically

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect, P1)

Description

[Mike Connor [:mconnor]]

Idea is to copy the bookmarks file once a day and create a backup with a
datestamp, along the lines of "bookmarks-YYYYMMDD.html".  Short version is FAT32
is not that robust, so we need a defence in depth for those users to have a real
backup.

- Need to have a method to determine the oldest of the backups and delete that
so we don't go overboard.
- probably want a pref to say how many backups to maintain.

Comment 1

[Mardeg]

Or... we could just put a radio button in Options so users can choose between a
"Favourites" or "Bookmarks" menu, with "Favourites" just directly accessing
their original IE Favourites without the need to worry about a single
easily-deletable/losable-when-profile-is-lost html file.

Although I know it's possible to do this by combining the "PlainOldFavorites"
and "Compact Menu" extensions.

Comment 2

[Peter van der Woude [:Peter6]]

just some thoughts...

> copy once a day ....

and at least copy if a bookmark(folder) is added or deleted, or after a
reordering , in BM, bookmarks menu or bookmarks toolbar.
(in other words if it's obvious that the user is changing something)

and NEVER (?/!) when FF is closed, because that is where the loss trouble has
been coming from in the first place.

remove bookmarks.bak because they don't serve any purpose if this is implemented.

recover from latest bookmarks-[date].html

Comment 3

[Mike Connor [:mconnor]]

Attachment: patch

this also tweaks the behaviour implemented for bug 304403.  Normally, we only
archive once a day, so if an archive exists, we keep going.  However, if we're
reverting to the default bookmarks, we replace the current archive if it
exists, and only revert the bookmarks if the archive succeeds.

Right now, this is hardcoded to five backups.  I thought about implementing a
pref, but the additional overhead seemed a bit much.  We're hopefully not going
to need this for long on trunk, so I don't want to add even more prefs that
we're going to change later.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 193364 [details] [diff] [review]
patch

>+        if (i > 4) {
>+			PRInt16 numberOfBackupsToDelete = i - 4;
>+            bookmarksBackupDir->GetDirectoryEntries(getter_AddRefs(existingBackups));
>+            hasMoreElements = PR_FALSE;
>+            while (NS_SUCCEEDED(existingBackups->HasMoreElements(&hasMoreElements)) &&
>+                   hasMoreElements && numberOfBackupsToDelete) {
>+                existingBackups->GetNext(getter_AddRefs(backupFile));
>+                nsAutoString backupName;
>+                backupFile->GetLeafName(backupName);
>+                if (Substring(backupName, 0, 10) == NS_LITERAL_STRING("bookmarks-")) {
>+                    backupFile->Exists(&exists);
>+                    if (exists)
>+                        backupFile->Remove(PR_FALSE);
>+
>+                    numberOfBackupsToDelete--;
>+				}
>+            }
>+		}

Is this guaranteed to delete the oldest # of backups?  I have no idea if
GetDirectoryEntries makes any guarantees.. if it does, then this is ok I think.
 I have some additional ideas I'll try to implement tomorrow, adding some
sentinels into bookmarks.html so that we can tell if it's truncated on read.

Also, the patch has broken indentation.. there's tabs in a bunch of places. 
4-space space-only indents please!

r=vladimir with tabs fixed

Comment 5

[Mike Shaver (:shaver emeritus)]

GetDirectoryEntries will not make the guarantee you want for this on all
platforms, as a wrapper around readdir.  You need to fetch and sort yourself.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: updated patch

Updated patch to sort the file list and remove only oldest entries.

Comment 7

[Mike Shaver (:shaver emeritus)]

Comment on attachment 193966 [details] [diff] [review]
updated patch

r=shaver with changes from IRC.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: patch updated with shaver's review comments

Comment 9

[Mike Connor [:mconnor]]

-> vlad, for driving his updated patch in

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

In on branch and trunk.

Comment 11

[Ed Hume]

So far, I'm seeing a backup each on both trunk and branch build profiles.

Comment 12

[Peter Lairo]

5-Day backups are great. Even better would be to provide a more comprehensive
solution. A differentiated (daily) backup is most releveant in recent history (7
days), and becomes less relevant over longer times (weeks/months/years).

I therefore suggest a method that will result in the user always having:

- the 7 most recent daily backups
- the 4-5 most recent weekly backups
- the 12 most recent monthly backups
- EVERY annual backup.

Specifications:

- Maintain daily backups for 7 days (day 1 backup, ... , day 7 backup)
- The day 7 daily backup is also marked as "Weekly Backup 1".
- On day 8, delete the previous day 1 backup (keep weekly backup 1) and make a
new day 1 backup. 
- on day 2 (actually day 8), delete the previous day 2 backup and make a new day
2 backup. 
- The day 14 backup is is labelled "Weekly Backup 2" (keep weekly backup 1).
- Repeat this until a calendar month (from OS clock?) is reached. At this point
the user will have the 7 most recent daily backups and 4-5 weekly backups.
- On the last day of the month (day 28/29/30/31) the backup is labelled "Monthly
Backup 1" (e.g. "January") (if a previous "January" already exists, it is
deleted); etc for months 2-12.
- On the first of the following month (~day 32) delete the previous day 1 backup
and make a new day 1 backup; etc for days 2-7.
- On the 8th of the following month delete the previous week 1 backup and make a
new week 1 backup; etc. for weeks 2-5.
- Repeat this until a calendar YEAR (from OS clock?) is reached. At this point
the user will have the 7 most recent daily backups, the 4-5 most recent weekly
backups, and the 12 most recent monthly backups.
- On the last day of the year (day 365) the backup is labelled "Annual Backup 1"
(e.g. "2005") (if a previous "Annual Backup" already exists, it is NOT deleted);
etc for eveay year until infinity, or the user switches to IE. ;-)

The most backup files a user will ever have is 24 (7d+5w+12m), plus the number
of annual backups. So, after 10 years the user would have 34 (24+10) backup
files. That's not too much for a comprehensive backup system. :-)

The filenames should be human understandable. Suggestion:
- ORIGINAL: bookmarks.html
- DAILY:    bookmarks.html_20050830_D.bak      (d2 = always a Tuesday)
- WEEKLY:   bookmarks.html_20050828_W.bak      (w4 = 4th Sunday of month)
- MONTHLY:  bookmarks.html_20050931_M.bak      (m9 = always September)
- ANNUAL:   bookmarks.html_20051231_Annual.bak

This would also make the files *sorted chronologically* in the OS's file browser.

Of couse, there would need to be some error-checking mechanism if the user
deletes or renames a backup file. I suggest to ignore missing files, and to
simply (re)create them as needed (e.g. "day 4 backup").

If a weekly, monthly or annual backup cannot be made on the scheduled day (user
doesn't load Firefox), it is made on the next possible day (i.e., the next time
the user loads Firefox).

PS. Yeah, Yeah. I know this is probably a new bug. vlad: What should I do?

Comment 13

[manc39]

This is a great bug to see fixed, but perhaps the backups should be stored
outside of the profile, maybe in the same location as profiles.ini? They'd have
to be prefixed with the profile name of course, to separate different profiles'
backups.

Comment 14

[Peter van der Woude [:Peter6]]

*** Bug 285619 has been marked as a duplicate of this bug. ***

Comment 15

[Marc Croteau]

(In reply to comment #0)
> Idea is to copy the bookmarks file once a day and create a backup with a
> datestamp, along the lines of "bookmarks-YYYYMMDD.html".  Short version is FAT32
> is not that robust, so we need a defence in depth for those users to have a real
> backup.
> 
> - Need to have a method to determine the oldest of the backups and delete that
> so we don't go overboard.
> - probably want a pref to say how many backups to maintain.

Is there a way to disable this feature (which I personally don't like) ?

I looked through the various config parameters and found nothing.

What about a browser.bookmarks.backup variable with a boolean value ?

When looking at the cpecifications of comment #12, I also think it would be a good idea to have those parameters editable through the GUI.

Comment 16

[Adam Guthrie]

*** Bug 336770 has been marked as a duplicate of this bug. ***

Comment 17

[Worcester12345]

The features of the "Bookmark Backup" extension do more than this, and more. Is there any conflict in still running the extension?

Comment 18

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #17)
> The features of the "Bookmark Backup" extension do more than this, and more. Is
> there any conflict in still running the extension?

No.