GNOME Bugzilla – Bug 147380
[Balsa removes files without prompting user]
Last modified: 2005-01-28 13:47:34 UTC
1.) Install Pine, which will create and store all mail in $HOME/mbox (a file) 2.) Run pine, pull some mail across (or send some test messages to yourself) 3.) Quit pine 4.) Install Balsa (leaving pine installed) 5.) Run Balsa, configuring with the defaults 6.) Create a new mbox file, pointing to $HOME/mbox 7.) *BOOM*! The file called $HOME/mbox is now a 0-byte file I was just bitten by this, and lost 7,000 messages in my main Inbox. I use pine daily, as I have for years.. and have never lost this much mail. I have a backup, thankfully, from a week ago, but Balsa *DEFINATELY* should not have just truncated this file to 0-bytes. Ideally, checking for the existance of the file about to be opened, should happen first, before nuking it or overwriting it. $HOME/mbox is the hard-coded default for pine's configuration, and has been for years. Bad bad bad, Balsa, BAD!
Let's handle this step by step. First the subject looks wrong as Balsa doesn't treat any filename diferent. Have you tried to reproduce or did it happen just once ? Have you reproduced with diferent file names ? What format were you using with Pine ? Mbox ? Also, Pine didn't create ~/mbox for me. Doesn't pine use ~/mail/ by default ? I couldn't reproduce this at all. Balsa just opened a Mbox and when I tried to add a non mailbox file as Mbox it complained the selected file wasn't a MBox and didn't add it to the list.
Some more detail, 100% reproducable: Pine, via Debian's build, uses $HOME/mbox (a file, in mbox format, with the name 'mbox') for the "Inbox", as seen by pine. All other mail is stored under $HOME/mail, by default. This is not in ~/.pinerc, it is hard-coded in the source of Pine itself (I'll pull the source deb package later and find the exact lines). I installed Balsa via the standard Debian mechanism, which pulled in all of my mboxes under $HOME/mail, as expected (about 1gb of mail in 200+ mailboxes, all in mbox format, with various names). I then right-clicked on the Inbox in Balsa, and asked went to properties, and pointed it to $HOME/mbox, and clicked update. My $HOME/mbox is now 0-bytes. There are a few other issues with trying to open an mbox file called 'mbox' in Balsa as well. I deleted $HOME/.balsa and $HOME/.gnome2/balsa, and restarted the configuration from scratch, this time taking the defaults. I right-clicked on the file tree, and went to New -> Local mbox file, and pointed it to $HOME/mbox and clicked "Add". I expected it to show up in the tree. It didn't, so I right-clicked and selected "Rescan". Nothing happened. I exited Balsa, and restarted it, and went through the same process again (right-click -> New -> Local mbox), and it added it the second time, oddly. So the first part of this problem is what truncates my mbox to 0 bytes, presumably by copying a blank /var/mail/username file (which doesn't exist at all on my system) to $HOME/mbox, without any checking. To verify this, I deleted $HOME/.balsa and $HOME/.gnome2/balsa and restarted the initial setup again, but this time, pointed "Inbox" in the druid to $HOME/mbox directly, instead of taking the defaults. When Balsa started, I saw my test copy of $HOME/mbox as expected, with all messages intact. I then went to Properties on the Inbox in Balsa, and pointed it to /var/mail/username, and exited Balsa. Now in /var/mail, there is an mbox file called 'username' with the exact same size as the one in $HOME, and the one in $HOME is gone. Definately not the expected, or desired behavior overall.. trashing mail without prompting is *BAD BAD BAD*.
Re pulling pine's deb, don't bother :) Re copying /var/spool/mail to ~/mbox, it doesn't. Re everything else, totally uncanny. I forgot to ask, what balsa version are you using ?
Sorry, version 2.0.17.
I see the problem. I was wrong about /var/spool/mail to ~/mbox cause I wasn't understanding what you did. What you did was move your Inbox (eq mv /var/spool/mail/user ~/mbox). What you wanted to do was New->Mbox and Mark as Inbox. Balsa should issue a warning about overwriting an existing file! It doesn't cause as far as I can remember you're the first to do this. I still don't see the issue with the filename 'mbox'. (btw, could you please change the subject to something more relevant)
Created attachment 35306 [details] [review] Patch to disallow renaming of a local mailbox to an existing file Selecting a new path for a local mailbox calls rename() which does not check the destination before overwriting it. This patch returns an error if that is attempted. The user can always move messages later, to merge the contents of mailboxes. This begs the question: Why is there a browse button in the properties dialog of an existing mailbox, if overwriting an existing file will lead to an unfortunate series of events?
Thanks for the patch! Committed (with C-style comment, and re-indented). Resolving as FIXED...