Exporting/Importing Buddy List in Pidgin

2,776 views
Skip to first unread message

geekfella

unread,
Sep 18, 2008, 12:20:43 PM9/18/08
to libraryh3lp
Thought someone in the libraryh3lp community might have figured this
one out already. Using the Pidgin client, what is the best way to
export a buddy list and then import into a new installation of pidgin?

The normal data folder for pidgin is located at C:\Documents and
Settings\username\Application Data\.purple and inside this folder is
an .xml file called blist.xml....

I have tried to take this blist.xml and manipulate it (do a find and
replace on the appropriate username and then copy it over), but it
doesnt seem to work cleanly....

Anyone else figure this out yet?

Also, if anyone is interested I was able to find on the web the
registry location that controls where the path to these logs are
stored and how to change them....
http://www.lib.unc.edu/reference/eref/pidgin/env_var.html

The registry location is here with an example of the path
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
\Environment]
"purplehome"="G:\\PIDGINSTUFF"

For example, I work for a County Library and we need to keep copies of
our electronic communications. We have our My Document folders mapped
to a central file server for our clients. I made a folder inside
there My Documents called pidgin_logs and then put a path of \
\servername\username\pidgin_logs in the strValue below....

If the user already had a pidgin account, I then copied their .purple
folder inside the pidgin_logs folder....if you are setting this up for
the first time (not copying over an existing account), you will need
to create a .purple folder inside the pidgin_logs......

You will need to restart (or just log out of the windows account I
beleieve) for these changes to take effect.....now you have long term
retention of your chat logs on a centralized server so that if a
computer goes belly up, needs to be reformatted, etc. you wont lose
the logs....

What this does then is to make it so that Pidgin logs go the the
central file server and not to the local computer
an example of a vbs script that could be used to change this to the
appropriate path is here...as I develop more stuff, I will glady share
it here......

My next project is to try and write a script that will auto-install
pidgin on a group of computers, rather than having to go to each
individual system....If i figure it out, I will share it here.....

const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set StdOut = WScript.StdOut

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")

strKeyPath = "SYSTEM\CurrentControlSet\Control\Session Manager
\Environment"
strValueName = "purplehome"
strValue = "path to central .purple folder" ' example \\servername
\username\pidgin_logs
oReg.SetStringValue
HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

Eric Sessoms

unread,
Sep 18, 2008, 5:30:28 PM9/18/08
to geekfella, libraryh3lp
Pidgin's blist.xml is just a cache. This is true regardless of
protocol: buddies are stored on your IM provider's server and read by
the client on login. There is no need to preserve the file for a new
installation for the same user, and copying the file to a new user
will not create new buddies.

--
not about to see your light

Pam Sessoms

unread,
Sep 18, 2008, 6:05:26 PM9/18/08
to geekfella, libraryh3lp
Thanks for sharing your centralized log storage solution and your VBScript!

One possible point of complication involves using the purplehome
variable on multiple computers; this is because it centralizes
Pidgin's accounts file in addition to the logs. This means that it's
easy to have operators mistakenly all using the same account to sign
in, which winds up defeating most of the purpose of multi-operator
libraryh3lp routing. One fix it to specify a slightly *different*
sub-folder path for each computer. That way, they'll all be able to
have separate operator accounts and logs on a network drive. You can
point Windows' search feature at the top-level folder to flatten the
directory structure when working with log files; the logs end in .txt
and you can specify a modified date, etc...

If you're storing transcripts on libraryh3lp's server, you can also
bulk download and delete them (and/or save the call history
information to a csv file). http://libraryh3lp.com/calls/ Speaking
of nifty hacks, the api for the calls history is open so that it's
possible to write scripts to do things like automatically harvest
these transcripts (download, then delete).

Best,
-Pam.

On Thu, Sep 18, 2008 at 12:20 PM, geekfella <eye...@gmail.com> wrote:

--
Pam Sessoms, Electronic Reference Services Librarian
phone 919/962-1151; fax 919/962-5537; AIM: SessomsPam
Walter Royal Davis Library, Reference Dept.
UNC-Chapel Hill, CB 3922
Chapel Hill, NC 27514-3922

geekfella

unread,
Sep 23, 2008, 11:30:57 AM9/23/08
to libraryh3lp
Just for future clarification, I am storing the data in seperate
folders for each user on a file server, rather than store all users
data in one folder, for the reasons you mentioned....

It is interesting that the source of this hack (http://www.lib.unc.edu/
reference/eref/pidgin/env_var.html ) does seem to store it centrally,
and lists the benefits and issues....
> Chapel Hill, NC 27514-3922- Hide quoted text -
>
> - Show quoted text -

Pam Sessoms

unread,
Sep 23, 2008, 11:42:12 AM9/23/08
to geekfella, libraryh3lp
On Tue, Sep 23, 2008 at 11:30 AM, geekfella <eye...@gmail.com> wrote:
> Just for future clarification, I am storing the data in seperate
> folders for each user on a file server, rather than store all users
> data in one folder, for the reasons you mentioned....

Cool, that's great. I pretty much figured you already had that in
hand. :) I've seen people struggle with this in the past and wanted
to be sure no one finding this thread down the road would get tangled
up in the accounts thing.

> It is interesting that the source of this hack (http://www.lib.unc.edu/
> reference/eref/pidgin/env_var.html ) does seem to store it centrally,
> and lists the benefits and issues....

Yeah, I need to update that web page so that it is more detailed. It
worked as described for us for a long time because of some procedures
and the staffing model we had in place when I originally wrote the
page. Nowadays, we don't store the logs locally, and I just harvest
them off of libraryh3lp's server as needed.

Best,

-Pam.

Reply all
Reply to author
Forward
0 new messages