Open Bug 80706 Opened 23 years ago Updated 4 years ago

Address Book unable to handle absolute path in prefs.js

Categories

(Thunderbird :: Address Book, defect)

Product:
Thunderbird
Component:
Address Book
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: d.bz-mozilla, Unassigned)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-didier i686; en-US; rv:0.9)
Gecko/20010507
BuildID:    20010505

For the purpose of sharing address books :
When manually changing the user_pref("ldap_2.servers.testab.filename") entry in
prefs.js to an absolute path (e.g. "c:\\abook-1.mab"), a crash occurs in
ADDRBOOK.DLL. Paths relative to the salted profile path (e.g.
"relative\\path\\abook-1.mab") seem to work.




Reproducible: Always
Steps to Reproduce:
1. Edit prefs.js
2.
3.

Actual Results:  Application error in ADDRBOOK.DLL
Severity: normal → critical
Keywords: crash
Additional steps to reproduce :

1. exit Mozilla
2. edit prefs.js as stated
3. start Mozilla
4. open Address Book
5. Add a new card in the testab AB
6. press OK to add the new card --> crash
QA Contact: esther → fenella
A fix to this crash could provide Mozilla with a not to be underestimated added
value :

Allowing for an absolute filepath in the prefs.js gives a sysadmin the
opportunity to define system-wide addressbooks in a multi-user environment by
entering a network-drive based filepath ; this could prove to be a very
acceptable alternative to LDAP-based adressbooks !

For the sake of AB integrity, server-defined R/O and R/W rights should be honoured.


moving to future milestone.
Target Milestone: --- → Future
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Win32 (2001-05-30-06 trunk) on win-nt 4.0
Crash still exists.
I don't have this pref, how do I get it, so I can reproduce the crash and
possibly get a stack?
Relevant part in prefs.js :

user_pref("ldap_2.servers.testab.description", "AB test AbsPath");
user_pref("ldap_2.servers.testab.dirType", 2);
user_pref("ldap_2.servers.testab.filename","C:\\abook-2.mab");
user_pref("ldap_2.servers.testab.isOffline", false);
user_pref("ldap_2.servers.testab.position", 7);

(off course, to be sharable, 'testab.filename' would point to a network drive
instead of C:\)


fyi: I found the prefs.js file in
c:\WINNT\profiles\fenella\application 
Data\mozilla\users50\fenella-1\4p3uzz9p.slt
Keywords: nsenterprise
Still crashes in Win32 build 2001-07-24-09 ; talkback reported.

FYI : Behavior in Netscape Communicator 4.76 (Win32) :
Defining an absolute path in prefs.js works OK, no crashes, but addressbook
entries are only visible to first user (subsequent users, don't get an error,
but the addressbook seems empty : probably a sharing issue).


Fixing this crash bug (that is, absolute path definition & at least read-only
access) would allow for shared addressbooks in an enterprise environment.


adding nsenterprise-
Keywords: nsenterprise → nsenterprise-
QA Contact: fenella → nbaca
this only happens when you manually edit prefs, right?

if so, that makes it lower priority.  but I'd still want to fix it, since it is 
a crasher.
Assignee: chuang → sspitzer
This seems to work for me with the 2002-01-08 Win2k build:

user_pref("ldap_2.servers.testab.filename", "C:Documents and 
SettingsAdministratorApplication 
DataMozillaProfilesdefaultiwqvynl.sltabook.mab");

and then choosing that book in the left pane and then clicking New Card.
(Sorry it has taken me so long to follow-up, but as I wsa quite swamped with
work (aren't we all), I decided to postpone testing on this bug till the next
milestone).

OK, tested with 0.9.8.

ADDRBOOK.DLL does not crash anymore, however it is still impossible to define an
absolute path for an address book.

Using FileMon (File Access tracer, http://www.sysinternals.com), reveals that
the user's Mozilla profile path gets injected in the user_pref ldap.filename, e.g. :

(a) user_pref("ldap_2.servers.testab.filename", "testsubdir\\abook.mab");
(b) user_pref("ldap_2.servers.testab.filename", "c:\\testsubdir\\abook.mab");

(a) works OK ;
(b) gets mapped to C:\\Program
Files\\mozilla.org\\...\\c:\\testsubdir\\abook.mab , and subsequently fails.


This is an inconsequence, as e.g. the parameter for the cache
("browser.cache.disk.parent_directory") allows for an absolute path too.

It would be nice if Mozilla would refrain from injecting the profile path, as
the current behaviour prohibits e.g. network-drive based sharing of address books.
Tested with nightly 2002032708 (Win).


Changing the following pref in a clean profile :

user_pref("ldap_2.servers.testbook.filename", "file://C%3A%5Cabook-1.mab");

results in mozilla.exe still searching for :

C:\Documents and Settings\didier\Application Data\Mozilla\Profiles\DMBR
User\xxx.slt\file:\C%3A%5Cabook-1.mab

instead of :

C:\abook-1.mab



Um, file:/// takes three forward slashes, I thought?
Replacing :
user_pref("ldap_2.servers.testbook.filename", "file://C%3A%5Cabook-1.mab");

with :
user_pref("ldap_2.servers.testbook.filename", "file:///C%3A%5Cabook-1.mab");

results in mozilla.exe still searching for :

C:\Documents and Settings\didier\Application Data\Mozilla\Profiles\DMBR
User\xxx.slt\file:\C%3A%5Cabook-1.mab

No apparent change, whether 2 or 3 slashes are used. As I pointed out in comment
#13 , the pref filename gets appended to the user's directory , whether or not
an absolute path is defined in the pref, resulting in an invalid filename in the
latter case.


On the other hand, pref :
user_pref("browser.search.defaultengine",
"engine://C%3A%5CProgram%20Files%5Cmozilla.org%5CMozilla.nightly%5Csearchplugins%5Cgoogle.src");


allows for an absolute filepath.




Tested with Mozilla 1.1 (20020826) :

It's still impossible to refer to an address book file outside the salted
directory, rendering shared address books impossible.
Keywords: crash
The bug can not repro with Mozilla 1.1b
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1b) Gecko/20020901
Comment #18 : did you check in a Windows environment ?
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Can someone test this on a windows build please and see if it is still a 
problem?
Keywords: qawanted
Test in Mozilla Suite or Thunderbird ?

Preferably test the suite, as that is where the original bug was, but it
wouldn't hurt to test it in thunderbird as well.
Tested in both Mozilla Suite 1.7.8 (Win) and Thunderbird 1.0.2 (Win).

Both Moz and ThB still behave as explained in comment #13  : the pref.js-defined
absolute path for e.g. abook.mab gets appended on the absolute salted path,
leading to an inaccessible address book.

This happens with both standard Windows file system (C:\...) and URI
(file:///...) nomenclature in prefs.js.



Didier: if you can, please re-summarize this bug so as to be more precise (since
the crash is no longer reproduceable).  Thanks!
Stephen : is there a way to easily *duplicate* this bug report to the
ThunderBird product (Mozilla Suite being no longer actively developed), or
should I just reassign ?
Severity: critical → major
OS: Windows ME → Windows XP
Summary: crash in ADDRBOOK.DLL when entering absolute path for AB in prefs.js → Address Book unable to handle absolute path in prefs.js
Didier: feel free to shuffle it on over to Thunderbird: bugs fixed there will
most likely be backported to the Suite by someone at sometime.

Actually, let me do that right now...
Product: Mozilla Application Suite → Thunderbird
Assignee: mail → mscott
QA Contact: nbaca
Ok, this looks like the problem area, we expect address books to be in the
profile directory:

http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbMDBDirFactory.cpp#141

There's probably some other places as well, however is it such a good idea
allowing the address book outside the profile directory? AFAIK address books
aren't currently designed to be shared among apps and one app updating it whilst
the other is using it could prove problematic.

I'm hoping David or Dan may be able to provide a better insight into this.
IMO, the main advantage of an address book outside the profile directory would
allow for user-shared address books (kind of poor man's LDAP) : see comment #2.

It's up to the sysadmins to make sure the shared address books are marked read-only.
QA Contact: address-book
(In reply to comment #27)
> Ok, this looks like the problem area, we expect address books to be in the
> profile directory:
> 
> http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbMDBDirFactory.cpp#141
> 
> There's probably some other places as well, however is it such a good idea
> allowing the address book outside the profile directory? AFAIK address books
> aren't currently designed to be shared among apps and one app updating it whilst  the other is using it could prove problematic.

Mark, you recently wrote something about this in a newsgroup, no?
Assignee: mscott → nobody
Also, is there any chance of interaction between the subject of this bug and the hidden file issue described over in Bug 609074? Just want to cover the bases.
Target Milestone: Thunderbird 11.0 → ---
I managed to workaround this issue with creating a symlink, this can be done from vista and up i believe.
I am on win 7 pro and am running thunderbird 17.0.7

I have abook-4.mab on the share \\server\share\folder\ and ran this command in an elevated command prompt, while my working directory was the thunderbird profile directory:
mklink abook-4.mab \\server\share\folder\abook-4.mab

The address book can be updated without any problems
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.