Apache OpenOffice (AOO) Bugzilla – Issue 8210
unable to access readonly mozilla address book
Last modified: 2013-08-07 15:45:41 UTC
* On a system with Mozilla installed, make it's address book (abook.mab) write protected. * start OpenOffice.org, create a data source for the mozilla address book * open the data source browser, therein, open the address book data source, select the Personal Address Book => no data appears I think this may be a Mozilla bug, as in Mozilla, this address book does not even appear anymore at all. So I think we need to look for a Mozilla bug as well (or file one). But perhaps this is by intention in Mozilla (though I can't imagine any good reason at the moment).
John suggested (offline) that this is because Mozilla does not allow multiple access to profiles, thus it always opens the profile files with write permissions. To cite another guy, who brought this to a point: "A program cannot be expected to run beyond its specs, but a program's specs should allow for minimal operation in bad circumstances..." ((c) Cyrille Moureaux :) I think Mozilla fullfills the first part, but it's spec does not fullfill the second one :)
re-assigning responsibilities
targeting Marc, can you confirm this issue?
lowering priority
mass re-assign of address book integration issues
Hi Frank, unfortunately I can not reproduce your problem, because the description "create a data source for the mozilla address book" is much to general (for me). Can you pls. add a step by step instruction how you created the data source, then it should not be so difficult to test that. Thanks Rainer
* Tools|Data Sources * New * Type=Address Book * "..." -> "Mozilla address book" * OK * OK
I can confirm the reported effects with 1.1RC3 German version WIN98SE: 645m15(Build8669) [CWS:ooo11rc3] but now my problem is to understand, why you want to protect "abook.mab". My MOZILLA will not accept a write protected "abook.mab", too. What is your reason to protect it? Rainer
Well ... why doesn't Mozilla accept a write protected address book file? I don't remember the exact reason why I originally stumbled upon this, but I know that for some reason I *had* a readonly file, and didn't see anything. Most probably, this is a Mozilla problem (with nothing or not very much to be done in OOo), but for an OOo user, it may become a problem. Low priority (perhaps even only P5), but nevertheless a potential problem. Of course somebody could decide "it's not worth to fix this", but honestly, I am a *big* fan of tracking even minor issues instead of closing them because of unimportance. Importance is always subjective, and though most people don't really care about readonly address book files, some few may do. And even if nobody from the currently active developers will ever fix this - the mere fact that the problem is reported, confirmed, and *existent*, may result in somebody who *does* care fixing it.
I saw it in 1.1RC3, so I change version from 1.0.1 to 1.1RC3 I think we can make it NEW, because it exists, but before the issue can get started, we should see, wether this is a real problem or only a "academic" one. Actually I can not find a reason to protect that file, because MOZILLA does not work with write protected adressbooks, too. And "abook.mab" is not "some database", it is _the_ MOZILLA addressbook, which more or less only can be used reasonable if it is active for MOZILLA. I do not believe that this issue is a MOZILLA - problem. The "unreadable" addressbook file problem happens without any MOZILLA activity (I had no MOZILLA running when I tested), and a write protected addressbook is no longer a "real" MOZILLA addressbook, as above mentioned. Rainer
May be it would be good to check this problem for other OS. Rainer
Well, OOo uses Mozilla components/code for accessing the Address Book, so it *is* a Mozilla problem (perhaps only Moz, perhaps also OOo). For the "it's no address book": I could argue that then it's a *bug* in Mozilla, because why do they declare a readonly file as "invalid address book"? I agree that the problem may be of academic interest only, and I think this is pretty good reflected in the "Later" target and the "P4" priority (perhaps even P5 would make sense).
responsibilities changed
change subcomponent to 'none'
Migrate to a new account for security reasons.
working transfer
The same problem is reported in #i50846#.
analogue http://www.openoffice.org/issues/show_bug.cgi?id=50846 I set this issue to worksforme
-> closed