662858 - Provide Preference Variables to Control Size and Vacuum Frequency of places.sqlite

Status: RESOLVED WONTFIX

(Toolkit :: Places, enhancement)

Description

[David E. Ross]

For users who are sufficiently knowledgeable about the inner workings of Firefox and other Gecko browsers, provide the ability to control the size of the places.sqlite file blocks (in bytes) and to control the frequency with with places.sqlite is vacuumed (in days).  The defaults might remain 10 MB and monthly.  However, some users may have problems with those values.

Comment 1

[Patrick Groleau]

The possibility to  control the size of the chunks of the file Places.sqlite is a must have option. 
In companies where the mozilla profile are store on network drives with quotas, we must "control" the growth of space use by the users. Where I work,we must control 7000 users (I work in a College) who use Firefox for web browsing. If all the users must use a 10mb file, when the majority won't rally exceed 1mb in the old fashion style of the file), I can't accept this "default" size. Reserving 70gb of SAN disk for only bookmarks is a great amout of money for little. 
If the option of controlling the places.sqlite size are not included in future release, there a lot of chance that we will not upgrade the browser in our company.

Comment 2

[Rob Janssen]

I fully agree with the above.
This change causes quite some storage and badwidth waste.
Part of our users are on ADSL VPN with roaming profiles, and copying a useless 10MB file for every login/logout really hurts.
Please make it configurable so that we can set a more reasonable value, like 500K.

Comment 3

[David E. Ross]

The 10 MB size of places.sqlite could likely be reduced if history entries were not duplicated.  (See bug #686319.)

Comment 4

[Rob Janssen]

(In reply to Patrick Groleau from comment #1)

I established a workaround for this problem as follows:

- download sqlite3.exe and install it on the workstations
- create a logoff script via group policy
- make a logoff script that (in the Mozilla preferences directory) executes:

sqlite3.exe places.sqlite vacuum

This reduces places.sqlite to a reasonable size before the roaming profile is mirrored back to the server by Windows.

Finding the profile directory can be tricky because of the salt directory, but
for managability we already have installed the software in such a way that all our users have the same profile subdirectory name (under their own profile dir).

Comment 5

[David E. Ross]

Re comment #4:  The workaround is clearly not intended for end users.  The RFE requested here is definitely for end users.

Comment 6

[Rob Janssen]

(In reply to David E. Ross from comment #5)
Sure, but when the water rises to your lips (as the saying is here) you have to do something, and getting an RFE implemented and have the situation persist in the meantime is simply not acceptable in situations like ours and Patrick's.

For end users the problem is not as critical because a 10MB file on a local disk is usually not a problem today.

We now have several sqlite3.exe commands in our logoff script to remove unwanted crud from Mozilla databases and to vacuum them,  Sure it would be better if Mozilla coders thought about this, but we are not in a position to force them.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

we don't plan to provide this sort of fine grained preferences.
Add-ons can do whatever they want though.

Comment 8

[David E. Ross]

If you close this as WontFix, please provide a justification.  

Re comment #6 and other comments relating to the file size:  The size of places.sqlite is not the issue.  The end-users (including me) do not care about the file size.  What we want is the capability to eliminate the marking of URIs as "already visited" after some elapse of time without having to manually delete them from the History window.  This was an existing capability that was removed despite complaints from end-users.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

growth is controllable through places.database.growthIncrementKiB
vacuum is not, for now it won't change, we should re-evaluate the vacuum strategy in general.