143451 - Changing "abook.mab" and "history.mab" file path locations

Status: NEW

(MailNews Core :: Address Book, defect)

Description

[António Duarte]

When I try to change the location of the "abook.mab" file by changing the line
  user_pref("ldap_2.servers.pab.filename", "abook.mab");
to
  user_pref("ldap_2.servers.pab.filename", "D:\\Address Books\\abook.mab");
(or other folder) in the "prefs.js" file, the "Personal Address Book" disapears
from the Address Book window.
Is there a reason for this? Why can't I change the location of the file?

Comment 1

[Ted]

The same thing that happened to nbaca happens to me when I try changing the
location of the "abook.mab" file via:
  user_pref("ldap_2.servers.pab.filename", "C:\\Ted\\abook.mab");
Is this the correct user_pref for pointing to the Personal Address Book?  The
Mozilla Cross Reference didn't find it
(http://lxr.mozilla.org/seamonkey/search?string=ldap_2.servers.pab.filename).

Comment 2

[Michael Gabriel]

*** Bug 146803 has been marked as a duplicate of this bug. ***

Comment 3

[Steve McMillen]

I would like to second this feature request.

The location of the address books should be editable in the user_pref.js file so
that I can share address books between multiple computers that I work on by
putting the files on a fileserver (my laptop).  Doesn't really need to be
configurable through the UI prefs dialog since its probably an advanced user
feature. 

Comment 4

[punkadiddle]

Problem still exists in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030411

Anyone working on this?

Comment 5

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 6

[Neill Martin-Rolsky]

I have the same problem and vote for this change.  We are a business with a LAN.
 Users need to be able to access their address books from any work station on
our LAN, just like they can access the other components of their NS7 email
accounts.  Version 4.x allowed this.  Version 7 should continue it.

I honestly don't know... is it really that hard to do this, or does it pose some
serious difficulty elsewhere in the program?

Comment 7

[Neill Martin-Rolsky]

I'm sorry, I need to amend my previous comment.  When I was typing, I referred
to NS 7, I meant to refer to the Mozilla build.  We have been using Netscape
version 4.79 and have not switched to version 7 or to Mozilla because of this
problem.  

Unfortunately and not surprisingly, version 4.x continues to fall behind as web
page architecture evolves & stricter security requirements are imposed by ISPs.
 It is becoming increasing difficult to resist the pressure to switch to IE &
it's affiliated email programs.  The change proposed here would make Mozilla (or
NS7, for that matter) a useful alternative for LAN-based enterprises.

Comment 8

[Joe Infla]

*** Bug 158495 has been marked as a duplicate of this bug. ***

Comment 9

[Joe Infla]

This also affects the Collected Addresses book, history.mab.  Adding keywords to
summary

Comment 10

[punkadiddle]

Problem still not fixed in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040623

Comment 11

[Lucian Fratila]

(In reply to comment #6)
> I have the same problem and vote for this change.  We are a business with a LAN.
>  Users need to be able to access their address books from any work station on
> our LAN, just like they can access the other components of their NS7 email
> accounts.  Version 4.x allowed this.  Version 7 should continue it.
> 
> I honestly don't know... is it really that hard to do this, or does it pose some
> serious difficulty elsewhere in the program?

Same thing here - what are the technical difficulties against this?

Comment 12

[S. W. B.]

(In reply to comment #6)
> I have the same problem and vote for this change.  We are a business with a 
LAN.
>  Users need to be able to access their address books from any work station on
> our LAN, just like they can access the other components of their NS7 email
> accounts.  Version 4.x allowed this.  Version 7 should continue it.
> I honestly don't know... is it really that hard to do this, or does it pose 
some
> serious difficulty elsewhere in the program?


I would also like to vote for getting this bug fixed.  I would like to use this 
for a simple shared addressbook (all users are directed to the same shared 
abook.mab).  Any suggestions?

Comment 13

[ago]

Same thing... 

+1 vote

NOTE: in order to use a .mab file as a poor man shared addressbook on a LAN,once
this bug is fixed, two things are required:

1) It is necessary that each client re-read (and parses) the file before writing
back any changes....  So each save operation (AFTER ok is pressed on the "Edit
Card" dialog) should really be: read all + edit single contact + save all...
Otherwise when a user makes a change on one contact he will overwrite any change
by other users since his last read operation (i.e. since he started TB)... It
should probably be a quick hack... 

2) It would be nice to check automatically every X minutes if the modified time
of the .mab file changed (i.e. the file was edited externally) and if so reload
the file...

It would be nice to have a preference to turn on read-before-write for people
who want poor man shared calendar (and understand the risks involved in using a
simple flatfile based backend)... As well as a preference for aureload... 

Better approach (longer term) would probably be to base addressbook (including
sharing capabilities) on UnifiedStorage
http://wiki.mozilla.org/Mozilla2.0?UnifiedStorage

Comment 14

[ago]

AB seems to put a write access lock on mab files. So sharing the same file is
not possible. 

If you just want to put it on a "remote" folder without sharing then you can
move all the profile in there and use relative path for the actual calendar. In
linux you can also use symbolic links.  

Comment 15

[Tomoo Nomura]

In case of dual boot system ( Windows & Linux ), sharing abook.mab and
bookmark.html is very convinient.  Using upper level short cut of Windows can
achieve it, but some file pathes in prefs.js can not be shared. ex.
F:\\mozilla\\Mail\\LOcal Folder in Windows, while /home/mozilla/Mail/Local\
Folder in Linux. Solution is to share only abook.mab and bookmark.html.

Comment 16

[ago]

Well I managed to actually "share" abook, in the sense of pointing several
clients to the same file, but because of the lock, the file cannot be shared not
even in read-only mode. Only one client can see it at any one time. At least
this is my experience.

Comment 17

[Chris Dempsey]

+1 vote

Additionally, it would be nice if multiple address books could be placed in multiple locations.  My office 
currently uses Eudora 5, which allows for both personal address books and a number of shared address  
books.  While I want users to be able to add to and edit their own personal address books, I only really 
care about them being able read the shared books.  I can enforce read-only with file permissions.  The 
entire campus does maintain an LDAP server, which we do use, but it is a bit overkill for this type of 
need, and does not need to be shared with the rest of the campus.

Comment 18

[ago]

> I can enforce read-only with file permissions.  

That won't help with current implementation of TB, since it requires r/w access
even to simply show the addressbook.... It looks like addressbooks are always
opened in r/w mode... 

I managed to create a "shared" addressbook using a very dirty trick to work
around the path issue and the r/w access limitation. I moved TB profiles on a
(samba) shared folder, so that they are not on the local machines (which is a
workaround for the path problem, and, as a bonus, it simplifies backups). I
added a shared.mab addressbook to each profile. I then have one person
addressbook (the master) to be copied periodically on each profile as
shared.mab. Other users can change entries in their shared.mab copy but their
changes will be overwritten at the next refresh... New chanegs from the master
copy are only visible when the addressbook is reopened. Other addressbooks are
obviously not affected. This gives you a very, very poor man shared r/o
addressbook... You should use ldap for a r/o addressbook, but if you want a
quick and nasty hack, that might be just enough... 

Having a r/o shared addressbook would be much simpler if:

1) A r/o flag was introduced, so that it won't complain when the file does not
have write permissions, and it won't try to display edit dialogs on that
addressbook...
2) More general paths (URI) were supported, not only relative ones. The main
object of this bug....
3) An autoreload mechanism

Were 1/2/3 implemented you would simply point all clients to the same file (with
r/o flag and an appropriate autoreload time), and give that file r/o permissions
to all except the master user... 

It would be even better if proper shared (multiuser r/w access) addressbooks
were implemented... Even so a file based r/o addressbooks will still be useful
as a simpler and more functional alternative to ldap.

Comment 19

[Frederic Denis]

I was looking for a simple way to share addresses information across our small
business and several times saw the name LDAP coming up...  Wouldn't it be just
nice to have a trimmed-down LDAP server built in Thunderbird?  Or is LDAP used
to store only e-mail adresses and name, not much more information?

If that was possible (again, I don't know much about LDAP), you could share your
addresses with any LDAP-supporting e-mail client...

Sounds fun to me (and usefull as a matter of fact...)


Fred

Comment 20

[Chris Dempsey]

(In reply to comment #19)
> I was looking for a simple way to share addresses information across our small
> business and several times saw the name LDAP coming up...  Wouldn't it be just
> nice to have a trimmed-down LDAP server built in Thunderbird?  Or is LDAP used
> to store only e-mail adresses and name, not much more information?

LDAP is a protocol for accessing directory information. Name and e-mail address
can be attributes within that directory.  Thunderbird can access a directory
server that speaks LDAP to look up names and e-mail addresses.  It is an LDAP
client, not an LDAP server.

However, LDAP is also a pretty heavyweight solution for sometimes very small
problems.  In my organization, we use a campus LDAP server with tens of
thousands of entries.  I would also like to be able to access a simple text file
or database that could store things like aliases.

For example, I don't want to build my own LDAP server to say:

chris.dempsey: [e-mail]
emergency: [e-mail]
cooldudes: [e-mail], [e-mail]

Comment 21

[Asa Dotzler [:asa]]

restoring nomination.

Comment 22

[Mike Cowperthwaite]

*** Bug 275086 has been marked as a duplicate of this bug. ***

Comment 23

[Mike Cowperthwaite]

*** Bug 234518 has been marked as a duplicate of this bug. ***

Comment 24

[Andreas Hussong]

+1 Vote

I would also like to vote for getting this bug fixed.
I want to safe my address book on a USB Flash Drive to use it on different
computers which are not permanently connected and run different operating systems.

Is their still no fix or workaround?

Comment 25

[Mike Bowler]

IMO - If the *.mab path problem gets fixed, the other requested changes
(multi-user, etc.) can be added on later.

Fixing this (hopefully small) change to allow different paths for the *.mab
would be a great start and beneficial to all.

Comment 26

[Harry Saal]

The article entitled "Sharing address books" in MozillaZine states that this syntax works for addressing an addressbook in a subdirectory of the user's profile.

user_pref("ldap_2.servers.pab.filename", "test\\abook.mab");

It does not appear to work for me using Thunderbird 2 alpha 1.

Does anyone know if the code present SHOULD permit this syntax or is the article in error??

Comment 29

[Keith Jillings]

It seems this bug isn't being addressed - it's been around for 7½ years with no change.   I've been struggling for a long time to keep address books synchronised between several machines - using batchfiles and running all the inherent risks.   Is there any hope of it being fixed?

I'm about to upgrade a load of machines to Windows 7, and need to know whether to install Thunderbird or another mail system.