Open Bug 609074 Opened 14 years ago Updated 9 years ago

address book won't save changes if .mab file has Hidden property set

Categories

(Thunderbird :: Address Book, defect)

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

Tracking

(Not tracked)

People

(Reporter: josh, Unassigned)

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 I spent quite a while updating the address book, and exited the program. When I went back in, my changes were not saved. I've done this several times and it's the same. I can't find anything in the Knowledge Base about this problem. Any suggestions? Reproducible: Always Steps to Reproduce: 1.enter data 2.exit the program 3.go back in again Expected Results: saved my changes using default theme
I finally managed to work around it -- went into the directory where address books are stored using Windows My Computer and changed the Properties by unclicking Hidden. Seems like Thunderbird could retrieve address books, but couldn't save changes because it didn't recognize the file it was updating? Also note that when I first noticed the problem, that I could enter changes in Address Book, but when I clicked OK in the Properties box, nothing would happen. I had to exit out of the Properties box by clicking the X in the upper right corner. The change would show in the list display of addresses, but would not save when I exited the program.
Controls for Properties windows. Yes, these are counter-intuitive and NOT consistent. The Add New Contact window controls work like you expect. BUT, open the Properties window and those controls do NOT work like you expect. Maybe that should be reported as a bug! It sure is annoying. Anyhow, had the same problem. Adding a Contact manually or via the "star" next to email addresses in message headers worked (contacts appeared in the AB) BUT as soon as TB is restarted, the new contact(s) are gone. Dropping n dragging them from Collected to Personal did NOT help nor prevent the loss. Locating the actuall AB data files (abook.mab and history.mab) and removing the "hidden" attribute fixed the problem. The files updated on the next try to add a contact and dragging an address from the Collected book to the Personal Address book worked as well. Now all that remains is to get someone to look at why the files were "hidden" ni the first place and add some code to TB to get around that problem!
Excuse my ignorance.... How does one go about making this change/checking the above issue?
In general, using Windows Search from the Start menu, search 'all files' on the C: drive for files matching this description: *.mab Windows will list all MAB files it finds (takes a few minutes - grab a diet-dew or poison of your choice). There should be at least one each of abook.mab and history.mab. These are your Personal Address and Collected Address books, respectively. Right-click the first filename in the list and select properties. At the bottom of the properties window is a couple radio boxes (circles) labeled 'Read-only' and 'Hidden'. Make sure both boxes are UNchecked and click Apply if it becomes active. Then click OK and move on to the next file on the list. Note to Firefox developers: How much trouble is it to add an attribute check to the start-up sequence and have it ensure the MAB files are un-hidden and non-write protected? This sort of problem is real hard for non-tech users to figure out because there is no direct correlation between the symptoms and the actual cause; and no error message pointing the way ... just failure to perform. Seems like a simple if-then would take care of this minor but annoying problem once and for all. Just a thought, and an excuse to tackle a no-brainer while thinking about something actually complicated. :-)
Sorry to report that this did not fix Bug 609074. They all boxes are unchecked. Thanks for the help.
(In reply to comment #5) > Sorry to report that this did not fix Bug 61692 . They all boxes are unchecked. > Thanks for the help.
Has anyone besides Joshua reproduced this? Joshua, Any idea how it got set to hidden? And have you tried to reproduce since comment 2
Severity: major → critical
Keywords: dataloss
Summary: address book won't save changes → address book won't save changes if .mab file has Hidden property set
I have not experienced this problem since Comment 4. I believe it occurred as part of a specific version upgrade (ie, an installation hiccup). If that is the case, reproduction will be virtually impossible. One could simulate the problem by setting the .MAB file's file attribute to Read-Only. If the problem was an installation glitch, installation program author's vigilance in re to proper file control sequencing will prevent further problems. Also, Thunderbird team could add a .MAB file attribute check on load to ensure they can properly access same. A very simple file access check at program load time would take care of this and the few extra seconds certainly will not be noticed in the onerous start-up time. Since no one else has reported this issue (also lending support to the idea that it was a system configuration-related glitch in one version update), and the corrective action (file attribute check) is easy to implement, I believe we can close this bug VERIFIED WORKSFORME. @Eric: not sure how this issue is related to Bug 61692 you mentioned above but that bug is reported to be Resolved Fixed in any event.
I experienced this problem (or very similar) when I upgraded to TB 7. I opened bug 691141 (which is likely a dup of this). My abook.mab file is not hidden or read-only.
Depends on: 691141
Confirming, I saw this happen on my parents PC (Windows XP) after they upgraded to Thunderbird 7. I don't think it's related to bug #691141 since they don't use the contact picture feature at all. The weird thing is that every address change seems to work until you quit Thunderbird. But when you launch it again, it's like nothing happened. I fixed this as suggested in comment #4 by unchecking the "hidden" flag on the MAB files in their profile. My guess is that something in the automatic upgrade process sometimes sets the file to hidden, which in turn unveils this old bug. See also https://bugzilla.redhat.com/show_bug.cgi?id=745787 and http://forums.mozillazine.org/viewtopic.php?f=39&t=2341733 which could be the same issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
No longer depends on: 691141
1) This solution - unchecking 'Hidden' for PROFILE .mab file Properties makes no damn sense! 2) It works!! It had confounded me for over a month. Many thx!
@Benoit: Actually makes good sense. TB accepts additions/changes, writes them to the live database in RAM, then tries to write them to the disc copy of the database. This fails because of the file's Hidden attribute. In other words, Windows "protects" the "hidden" file (even from its owner). Unfortunately, TB fails to report it's failure to store the changes. Naturally, when you restart, the changes aren't there because they never were (in the disc file). @David Gellman: As I said to Benoit, hidden files are protected; even from their owners. And it only gets worse after Windows XP. Many have had to resort to running as Admins all the time -- an incredibly bad idea IMHO -- just to get many programs to run properly. As I have said before, TB REALLY needs to run an access check on these files during startup so it can "fix" the problem before it is a problem. Four or five lines of code. Big deal.
First of all: Many thx for your advice - I NEVER would have found this answer on my own! And, at the risk of sounding argumentative, that was what didn't make sense: While I am fairly technical - but not very, I might have stumbled across a PROPERTY which showed the .mab file as "READ ONLY" and could interpret that as 'not allowing updates.' However, seeing 'HIDDEN' has always meant to me that it was just that: hidden, and not displayed in file lists - but still functional in applications. Regardless, I agree with you that TB/Mozilla should manage this issue in the application...and, again, thanks you for your help in resolving this vexing problem!!
Same problem encountered several weeks ago. Posted at Mozilla Support but no response. Stumbled on this post about an hour ago. Any email program using Mozilla has this problem - FossaMail, SeaMonkey, Thunderbird, Postbox, etc. Tried them all looking for one that didn't have the problem. They all work now after applying the fix described above.
Until Mozilla adds in a "file access" check for its MAB files this problem will crop up from time to time. It appears to be intermittent and will probably get worse as Windoze versions progress (as they seem to be getting more and more restrictive in regards to user rights). I believe the underlying idea is to eventually force everyone to run with administrative privileges which makes it easier for Microsoft to review and monitor what you're doing. In case you're thinking they're not interested in that stuff, read the EULA for Windows 10; it specifically gives them the right to peek over your shoulder; and disable your computer if they don't like what they see. But that is another whole thread, eh?
> But that is another whole thread, eh? Yes, not particularly relevant here John, could you provide the URL to the SUMO topic please? Is there any techincal reason to believe that this is limited to Windows users? And along those lines, Is anyone seeing this on linux? (first or second hand reports)
Flags: needinfo?(johng)
(In reply to Jim Scott from comment #12) > @David Gellman: As I said to Benoit, hidden files are protected; even from > their owners. And it only gets worse after Windows XP. Many have had to > resort to running as Admins all the time -- an incredibly bad idea IMHO -- > just to get many programs to run properly. Where do you take this from? I have never seen such behaviour in any Windows version, for hidden files. Maybe you mean the "Read Only" or "System" attributes?
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #16) > Is there any technical reason to believe that this is limited to Windows > users? > And along those lines, Is anyone seeing this on linux? (first or second hand > reports) I think this can't happen on Linux as there is no specific "Hidden" attribute. It is solved by putting a dot (.) at the start of file name. And then some file managers obey that convention and hide the files. At least this is on the common ext2-ext4 and reiser filesystems. I don't think Linux would obey the "Hidden" attribute if found on a FAT or NTFS filesystem (from a Windows partition). Linux does have a "read only" state, or at least setting up the perms on a file so that the owner can't write it.
I have tested the scenario here on Windows XP like this: - installation of TB nightly (43) - the TB profile is on a non-system partition (not in C:\documents and settings\name\application data) - created a new addressbook (AB) in TB - put some contact into that AB - restarted TB - edited contact - restarted TB - closed TB - made the abook-1.mab file hidden via the file manager - started TB - edited that contact again - restarted TB - the changes are there, properly saved - also looking in the file directly I can see the changes there So I have seen no problems. What am I doing differently that the reporters?
Annoyingly, the problem may be intermittent. The only solution (when it does occur) that I've run across is to hunt down the MAB files and de-select their Read Only and Hidden attributes. To be honest it has not happened to me since that 2010 entry (comment #4). Late in 2014 I was forced to upgrade to Windows 7 and the problem has not occurred on the new system either. @aceman: Microsoft's attempts to separate the user from the technical side of Windows began in earnest with XP, went into overdrive with Vista, and just kept getting more onerous with 7 then 8. As a result, any little thing can set off various Microsoft "protection" schemes. I had to resort to running as an Admin with Win 7 just to get some programs to run (they previously ran fine as Users under XP). Yes, this is a pet peeve with me ... but then I started with MS-DOS 1.1; back when one had total unfettered access if one was so inclined. As for Comment #12, sometimes Windows thinks Hidden files are also System files and guards them jealously (even from the creator / owner of said file). I cannot explain why or how their attributes get into that state but many things that happen "under the hood" with Microsoft are inexplicable so I just work out solutions and keep moving forward. Some noted that clearing the attributes worked WHEN they had a problem. Some noted that it did not. I do not mean to sound dismissive but there are too many variables in play for a proper thrashing of the problem IMHO. Ergo my suggestion to close this bug report (partially solved?) in Comment #8 still stands AFAIC. I would suggest opening another bug report if and when someone can find a reproducible error condition. I also believe you are correct in that this is strictly a Windows issue (although if one were to read protect the MAB files on a Linux system it would probably have the same effect). It is quite possible that the specific commands TB uses to access the MAB files have some quirk that Microsoft interprets as a "lock this file up when done" directive. I've not played with internal system commands since Windows 3.11 but I'm sure they've made it a lot more complicated since then! LOL
Just please do not mix "readonly" with "hidden" files here. If "hidden" files can't be written to (persist changes), that would be a problem and this bug. If "readonly" files can't be written to, that is a feature of the Operating system and there is no bug. TB could MAYBE warn the user if it wanted to write to a "readonly" file but then that would be necessary for all files it creates, which would be quite complicated. And I am not sure many programs do that.
Flags: needinfo?(johng)
Sure looks like a "real" bug to me. I've been struggling with this problem for weeks. Finally found this thread. The files were NOT set to "read only." They WERE set to "Hidden." Changed that. On the next try, changes to address list were properly saved on shutdown. Can't imagine why this hasn't been addressed. If "reproducibility" is needed, how about my last upteen weeks? One suggested fix was to export, delete those files, and import -- which worked briefly, then didn't. Wanna bet the files were recreated with the same property? I'll plan to report back after making additional changes to the address list. If the fix holds -- or if the files change back to hidden -- that would seem to confirm it's a bug. What exactly the bug is is beyond my capabilities -- but it sure looks like something in a recent Thunderbird release.
You need to log in before you can comment on or make changes to this bug.