moving global-messages-db.sqlite to a different location
divmediat
different location than the profile?
I'm used to all sorts of hex editing if necessary .
regards,
Christian Ander
Nathan Tuggy
thing to do, and it might help a lot if the ng knew what you are trying
to do with it. For example, are you trying to save disk space? share the
database? what?
Ben Bucksch
> To what purpose? Just moving the file does not seem like an obvious
> thing to do, and it might help a lot if the ng knew what you are
> trying to do with it. For example, are you trying to save disk space?
I, for one, think that gloda and the ImapMail / Mail dirs are too big to
be hiding as dotfiles or in the Windows profile. Just ~/.thunderbird/ is
about 1 GB for me, which is about 2/3 of my home dir (if I don't count
songbird and personal files).
I'd be good to allow the user (including UI) to choose the location, to
manage his disk space.
Nathan Tuggy
That sounds reasonable to me, and I'd rather like that capability too,
actually.
I was trying to elicit a few more details from the OP to narrow down
what sort of answer would be necessary. (Especially as there does not
presently appear to be any generalized way to move the file in question.)
petenz
I think it would be handy for there to be an easy way to manage the
location of one's entire profile folder - good for those who dual boot
or for backup situations where a specific folder is backed up regularly.
Andrew Sutherland
> I think it would be handy for there to be an easy way to manage the
> location of one's entire profile folder - good for those who dual boot
> or for backup situations where a specific folder is backed up regularly.
You can already do this. profiles.ini allows you to point at a profile
anywhere.
Useful links:
http://support.mozilla.com/en-US/kb/Profiles
http://kb.mozillazine.org/Profile_folder_-_Thunderbird
http://kb.mozillazine.org/Profiles.ini_file
Andrew
Ben Bucksch
That's great.
But doesn't solve the problem:
1) There needs to be UI for that, as normal users can have that problem
(my contact just told me that he has 4 GB of mail data)
2) It's important to differentiate primary user data (which can be
small) and (big) caches, as I have different backup stategies for these
kinds of data. gloda and ImapMail/ are both caches and huge.
Andrew Sutherland
> On 10.11.2009 05:53, Andrew Sutherland wrote:
> 1) There needs to be UI for that, as normal users can have that problem
> (my contact just told me that he has 4 GB of mail data)
The Profile Manager "Create Profile Wizard" lets you specify the folder
the profile should be created in. Sadly, there is no provision for
moving a profile.
> 2) It's important to differentiate primary user data (which can be
> small) and (big) caches, as I have different backup stategies for these
> kinds of data. gloda and ImapMail/ are both caches and huge.
I would argue the ImapMail directory structure is much more useful from
a backup perspective than the gloda database, but I agree with your
general premise that the profile directory (and our entire data storage
strategy) is not particularly friendly to most backup regimens involving
anything less than snapshot-able file-systems with copy-on-write-style
block-level semantics.
I don't suppose there is a standard among back-up programs where an
application can provide a definition file that explains what
files/folders are interesting and which are not?
Andrew
Wayne Mery
in mozilla? ha!
since I've been bebopping some of these bugs recently:
https://bugzilla.mozilla.org/show_bug.cgi?id=345070
Move cache outside of the regular profile folder
https://bugzilla.mozilla.org/show_bug.cgi?id=147344
Breaking up the profile for roaming, sharing and performance
https://bugzilla.mozilla.org/show_bug.cgi?id=408156
Ability to split prefs into multiple files
Siddharth Agarwal
> 2) It's important to differentiate primary user data (which can be
> small) and (big) caches, as I have different backup stategies for these
> kinds of data. gloda and ImapMail/ are both caches and huge.
To be honest, the right fix to this sounds like moving stuff to a cache
directory. Windows and OS X have this -- Linux doesn't, as the bug Wayne
linked points out.
I'd fully support moving global-messages-db.sqlite to the cache
directory, at least on platforms that support it.
Ben Bucksch
>>> 2) It's important to differentiate primary user data (which can be
>>> small) and (big) caches, as I have different backup stategies for these
>>> kinds of data. gloda and ImapMail/ are both caches and huge.
>>
>
> Move cache outside of the regular profile folder
Sounds like the right approach. This basically directly addresses my
above concern of separating primary-source user data and cache into
separate locations. The location needs to be configurable, though.
Henrik Zawischa
Henrik
Zagor
> In a Windows network with roaming user profiles it would be desirable to seperate configuration data and content related files. It is no problem to redirect the mail- and imapmail-folders to a different location, eg. the "Local Settings" or "AppData\Local" part of the Windows user profile. But the global-messages-db.sqlite still sits with the roaming data, cannot be moved. I have seen files with about 0.5 GB. Way to big for a roaming Windows profile.
>
> Henrik
My enduring gratitude will go to the hero who will carry out this, together with a donation to the Mozilla Foundation :-)
Thank you
Andrea
Fabien Romano
Note I also try to exclude the file from the roaming profile but windows gpo support folder exclusion, not files. Windows will also copy the file even if it's a link. I did not find this solution and I had to cook it so maybe some people around will find this helpfull.
The logon script will create a symbolic link from localappdata to appdata :
Get-ChildItem -Path "$env:localappdata\*" -Recurse -Filter global-messages-db.sqlite | % {
$destination = $(Join-Path "$env:appdata" $_.FullName.Replace("$env:localappdata\",""))
cmd /c mklink $destination $_.FullName
}
The logoff script check if the file is a symbolic link then delete it, otherwise it move the file to localappdata (the logon script will find it and create the symbolic link, before Thunderbird starts) :
function Test-ReparsePoint([string]$path) {
$file = Get-Item $path -Force -ea SilentlyContinue
return [bool]($file.Attributes -band [IO.FileAttributes]::ReparsePoint)
}
Get-ChildItem -Path "$env:appdata\*" -Recurse -Filter global-messages-db.sqlite | % {
if (Test-ReparsePoint($_.FullName)) {
Remove-Item $_.FullName
} else {
$destination = $(Join-Path "$env:localappdata" $_.FullName.Replace("$env:appdata\",""))
Move-Item -Path $_.FullName -Destination $destination
}
}
This can be done differently for sure, like moving the file instead of using a symbolic link. Does someone have a better solution ?
Fabien
ano nymo
> This can be done differently for sure, like moving the file instead of using a symbolic link. Does someone have a better solution ?
%USERPROFILE%\AppData\Roaming\Thunderbird\profiles.ini
we have
[Profile0]
Name=default
IsRelative=0
Path=O:\Thunderbird
Default=1
[General]
StartWithLastProfile=1
Version=2
-----------
O:\ is the users home directory
On the backup server we have a rule not to backup files called "global-messages-db.sqlite"
So the whole profile is not copied at every login/logout and the global-messages-db.sqlite files don't clutter the backups.
Matthias