80706 - Address Book unable to handle absolute path in prefs.js

Status: NEW

(Thunderbird :: Address Book, defect)

Description

[Didier Moens]

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

Comment 1

[Didier Moens]

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

Comment 2

[Didier Moens]

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.

Comment 3

[scottputterman]

moving to future milestone.

Comment 4

[Keyser Sose]

Marking NEW.

Comment 5

[fenella]

Win32 (2001-05-30-06 trunk) on win-nt 4.0
Crash still exists.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

I don't have this pref, how do I get it, so I can reproduce the crash and
possibly get a stack?

Comment 7

[Didier Moens]

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:\)

Comment 8

[fenella]

fyi: I found the prefs.js file in
c:\WINNT\profiles\fenella\application 
Data\mozilla\users50\fenella-1\4p3uzz9p.slt

Comment 9

[Didier Moens]

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.

Comment 10

[scottputterman]

adding nsenterprise-

Comment 11

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

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.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 13

[Didier Moens]

(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.

Comment 14

[Didier Moens]

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

Comment 15

[[e-mail] (gone - use [e-mail] instead)]

Um, file:/// takes three forward slashes, I thought?

Comment 16

[Didier Moens]

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.

Comment 17

[Didier Moens]

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.

Comment 18

[Mindy Liu]

The bug can not repro with Mozilla 1.1b
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1b) Gecko/20020901

Comment 19

[Didier Moens]

Comment #18 : did you check in a Windows environment ?

Comment 20

[Mark Banner (:standard8)]

Can someone test this on a windows build please and see if it is still a 
problem?

Comment 21

[Didier Moens]

Test in Mozilla Suite or Thunderbird ?

Comment 22

[Mark Banner (:standard8)]

Preferably test the suite, as that is where the original bug was, but it
wouldn't hurt to test it in thunderbird as well.

Comment 23

[Didier Moens]

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.

Comment 24

[Stephen Donner [:stephend] Not actively reading bugmail]

Didier: if you can, please re-summarize this bug so as to be more precise (since
the crash is no longer reproduceable).  Thanks!

Comment 25

[Didier Moens]

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 ?

Comment 26

[Stephen Donner [:stephend] Not actively reading bugmail]

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...

Comment 27

[Mark Banner (:standard8)]

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.

Comment 28

[Didier Moens]

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.

Comment 29

[Wayne Mery (:wsmwk)]

(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?

Comment 30

[Jim Scott]

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.

Comment 31

[guido]

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