The default bug view has changed. See this FAQ.

Create a dated bookmark backup file periodically

RESOLVED FIXED in Firefox1.5

Status

()

Firefox
Bookmarks & History
P1
normal
RESOLVED FIXED
12 years ago
5 years ago

People

(Reporter: mconnor, Assigned: vlad)

Tracking

({fixed1.8})

unspecified
Firefox1.5
fixed1.8
Points:
---
Bug Flags:
blocking1.8b4 +
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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.
(Reporter)

Updated

12 years ago
Status: NEW → ASSIGNED
Flags: blocking1.8b4+
Priority: -- → P1

Comment 1

12 years ago
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.
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


(Reporter)

Comment 3

12 years ago
Created attachment 193364 [details] [diff] [review]
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.
Attachment #193364 - Flags: review?(vladimir)
(Reporter)

Updated

12 years ago
Whiteboard: [has patch][needs review vlad]
(Assignee)

Comment 4

12 years ago
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
Attachment #193364 - Flags: review?(vladimir) → review+
(Reporter)

Updated

12 years ago
Attachment #193364 - Flags: approval1.8b4?

Updated

12 years ago
Attachment #193364 - Flags: approval1.8b4? → approval1.8b4+
(Reporter)

Updated

12 years ago
Whiteboard: [has patch][needs review vlad] → [has patch][needs checkin]

Updated

12 years ago
Flags: blocking1.8b5+
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.
(Assignee)

Comment 6

12 years ago
Created attachment 193966 [details] [diff] [review]
updated patch

Updated patch to sort the file list and remove only oldest entries.
Attachment #193364 - Attachment is obsolete: true
Attachment #193966 - Flags: review?(shaver)
Comment on attachment 193966 [details] [diff] [review]
updated patch

r=shaver with changes from IRC.
Attachment #193966 - Flags: review?(shaver) → review+
(Assignee)

Comment 8

12 years ago
Created attachment 193971 [details] [diff] [review]
patch updated with shaver's review comments
Attachment #193971 - Flags: approval1.8b4?
(Reporter)

Comment 9

12 years ago
-> vlad, for driving his updated patch in
Assignee: mconnor → vladimir
Status: ASSIGNED → NEW

Updated

12 years ago
Attachment #193971 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Comment 10

12 years ago
In on branch and trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Keywords: fixed1.8
Whiteboard: [has patch][needs checkin]
Target Milestone: --- → Firefox1.5

Comment 11

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

Comment 12

12 years ago
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

12 years ago
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.
*** Bug 285619 has been marked as a duplicate of this bug. ***

Comment 15

12 years ago
(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

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

Comment 17

11 years ago
The features of the "Bookmark Backup" extension do more than this, and more. Is there any conflict in still running the extension?
(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.
Duplicate of this bug: 365105
You need to log in before you can comment on or make changes to this bug.