903874 - RFE: make firefox more backup friendly

Status: UNCONFIRMED

(Core :: General, enhancement)

Description

[lsof]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130807125214

Steps to reproduce:

Backing up Firefox at the moment is a _pain_. There are cache files strewn around the profile directory, sub-directories containing log files and crash dumps. All of this intermixed with the good stuff: saved password, preferences and bookmarks.

Excluding all the transient stuff is a pain. I'd like to request that an RFE be considered to split transient disposable data into a separate directory which could be excluded. Some agreement would need to be come to with regard to addons (save which addons are installed as a preference, addon preferences are backed up anyway might be one option).

Comment 1

[Palmer Eldritch]

I had submitted https://bugzilla.mozilla.org/show_bug.cgi?id=868843 which was marked today as a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=804731 which blocks this one. In the bug I reported I had identified the (mostly undocumented) directories :

.\startupCache
.\Cache
.\jumpListCache
.\mozilla-media-cache
.\OfflineCache

and also (although not named as caches and nowhere documented apart from the source I guess)

.\thumbmnails
.\safebrowsing

as Caches.

I am syncing my FF profile via dropbox - I might as well copy and paste it but it's clear that dropbox is a much superior method of doing the same thing, because of many reasons (like cloud backup, _versioning_ (which saved my butt oftentimes), set-it-and-forget-it etc) - over many machines and occasionally operating systems SUCCESSFULLY. I stress the word successfully - successfully means that I run the exact same FF profile (addons, settings, bookmarks, sessions, passwords, tabs, scrapbook pages and in short _everything_ - bear in mind that my profile is several years old and several 100s of Mb) and in all those machines _with minimal to no glitches_ (since the very annoying behavior I reported here in https://bugzilla.mozilla.org/show_bug.cgi?id=696634 was fixed, sse the discussion there).

_It is very important that this behavior is preserved_. Bear in mind that dropbox is irrelevant - the behavior that must be preserved is that :

__copying the profile folder and pointing FF to the copy should get one in exactly the same environment__


So - much excited as I am to see this bug being addressed (the bug being the profile becoming a dumping place for _caches_) I urge you to consider _very carefully_ what should and should *not* be excluded from the profile.

In the spirit of firefox the answer should be : *about:config options*. I suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=868843 that the default setting for the cache(s) should be the OSs "Local Application Data" folder.

Crash dumps should probably (by default) stay in the profile for more "advanced" users, as should the logs. But _most importantly_ every change should be documented clearly - you could make a start by creating a page for this bug detailing at least the cache folders and gradually adding there other temporary/files folders.

If there is a program I really appreciate (despite slowing my PC to a crawl due to by huge places.sqlite, lazarus.sqlite etc :D) is FF - the reason being its open and customizable nature - and the fact that I can easily set up the exact same extra complex environment - which I have been tuning to my needs since _firebird_ - in any machine I am working on, by _just_ syncing out the folders I mentioned in DB - a huge feat actually. So please be careful here :)

Comment 2

[[:Aleksej]]

(In reply to Palmer Eldritch from comment #1)

Please note that I am not one of the people who are addressing this bug, and I am not really sure that marking your bug as a duplicate of that one was right.  But if you look at bug 259356's dependencies and bug 259356 comment 81, you'll see something was being done.  I've found that at least some Firefox linux-x86_64 builds use ~/.cache/mozilla/firefox for some or all of their caches.

Comment 3

[Masatoshi Kimura [:emk]]

> .\startupCache
> .\Cache
> .\jumpListCache
> .\mozilla-media-cache
> .\OfflineCache
> .\thumbmnails
> .\safebrowsing

> I suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=868843 that the default setting for
> the cache(s) should be the OSs "Local Application Data" folder.

AFAICT all of the above directories are already created under %localappdata%. What's the problem?

Comment 4

[Palmer Eldritch]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> > .\startupCache
> > .\Cache
> > .\jumpListCache
> > .\mozilla-media-cache
> > .\OfflineCache
> > .\thumbmnails
> > .\safebrowsing
> 
> > I suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=868843 that the default setting for
> > the cache(s) should be the OSs "Local Application Data" folder.
> 
> AFAICT all of the above directories are already created under
> %localappdata%. What's the problem?

They are not - at least *for a profile in a custom location* - they are created right in the profile folder. Is it a bug ? Maybe they should be moved to the %localappdata% on a next FF update ? Please post a bug and post the link here if you think it is - or reopen https://bugzilla.mozilla.org/show_bug.cgi?id=868843
Anyway there should be a way to specify this from about:config - preferably for all caches at once. Keep in mind that should be absolute-path-free - so it can be used in different machines/OSs

Comment 5

[[:Aleksej]]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> AFAICT all of the above directories are already created under
> %localappdata%. What's the problem?

My Beta profile uses ~/.cache/mozilla/firefox, and I've seen some in the account where I tested various Nightly builds.  The current Beta doesn't do that with a new profile.

Comment 6

[Masatoshi Kimura [:emk]]

Oh, I overlooked the "Platform: Linux". My bad.

Comment 7

[Palmer Eldritch]

(In reply to Masatoshi Kimura [:emk] from comment #6)
> Oh, I overlooked the "Platform: Linux". My bad.

I overlooked too i.e. my concerns were for windows. Should be platform-all - please change