62480 - Will Download Messages Even If No Write Permissions on Inbox

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[Brian Z]

Build ID:  2000120904

Situation:  Profile stored on Linux server, shared trhough SMB Networking
(Samba) for Windows Machines.  The Inbox's Permissions allow reading but not
writing for a given client machine.  I'm sure this could be reproduced locally
on a Linux machine, but I'm just giving my situation.

Go to that particualar cliet machine.  Open Mail.  Select the account heading
(not a folder - You could if you wanted to, but no messages would open & no
errors would be displayed - an error should be displayed).  Press the get new
messages button.

Expected: Warning to be displayed that Inbox could not be opened for writing.

Actual:  15 messages were received, deleted from the server, and lost forever.

That is why I marked this bug as critical.  Just so you know, I'm not upset at
Mozilla at all.  I was the one who accidently misconfigured the permissions on
the Linux Machine.

Thank you!

Comment 1

[Brian Z]

Shortening Subject.

I *think* this could be reporduced on a windows machine by setting the inbox to
read-only in it's properties.

Comment 2

[Keyser Sose]

When I set my premissions on the local inbox file to read only. It downloads the
messages fine but when I click on a message a dialog box pops up saying Unknown
Error. This is severe enough that I am going to go and mark it NEW so someone
will look at it ASAP

Comment 3

[Keyser Sose]

Whoops Marking NEW again

Comment 4

[Keyser Sose]

That really messed up Mozilla. Even after closing and reopening the Mail window
the messages are still there but anytime you try and do anything with them you
get "Unknown Error" luckly I had already set them to keep them on the server.

Comment 5

[Brian Z]

Is anybody going to do something about this bug?  It is very serious and can
lead to data loss/corruption!  It's been here for a month now.  Thanks!

Comment 6

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

Seth - there was a brief discussion on this in IRC and we didn't come up with a
bonafide resolution for this.  Could you add your comments?  Thanks.

Comment 7

[Brian Z]

Since still no action, nominating mozilla0.9 so someone reviews it.

Comment 8

[Bradley Baetz]

Attached is a minimal patch. If Inbox is not openable, then an error message is
displayed. Some more information about the problem would be good, but this fixes
it for me.

Note that this doesn't protect any of the other files (like the msf - when I
kept the msf writable but the Inbox file not writable, I had to delete the msf
to get rid of some "Unknown error"s). It also changes one test for the result of
new being !nsnull to just returning NS_OUT_OF_MEMORY. I think its correct (code
later down assumes that its not null), but I'm not sure.

Comment 9

[Bradley Baetz]

Attachment: Quick fix

Comment 10

[Keyser Sose]

Adding Updated Patch here in a second in mean time adding my name to CC: Sorry
for the spam

Comment 11

[Keyser Sose]

Attachment: Adding 2nd version of patch.. We still need to cleanup the Error Message which I will do once I get a hold of mpt.

Comment 12

[Boris Zbarsky [:bzbarsky]]

patch fixes the dataloss for me on linux.  Better wording is definitely
necessary, however.  ccing mpt

Comment 13

[Keyser Sose]

Attachment: Fix for Error Messages in DE, GB & US. Approved by MPT.

Comment 14

[Keyser Sose]

Adding review keyword.

Comment 15

[Keyser Sose]

Attachment: 3rd & Hopefully final version of patch - includes everything to be changed.

Comment 16

[Matthew T (active 1999-2002)]

`Mozilla [sic] could not write the email [sic] to the mailbox [sic]. Make sure 
the file system allows you write priveleges [sic] and enough disk space to copy 
[sic] the mailbox [sic].' ... Erk. I'd rather not be accused of having approved 
that, thanks. :-)

From the latest patch, and my discussions with Keyser on IRC, it seems that this 
is what we know when the error occurs:
* that we're trying to download POP3 e-mail messages to a particular folder (and
  not, for example, copying from one folder to another, or downloading newsgroup
  messages offline);
* the name of the destination folder.

This is what we don't know:
* the exact cause of the write failure (not enough disk space, read-only file,
  read-only folder, file locked by another app, disk has been ejected, whatever).

Given that, the error should look like this:

+---------------------------------------------------+
| Get Messages :::::::::::::::::::::::::::::::::::::|
+---------------------------------------------------+
| ,-. Your messages from {serverName} were not      |
| |X| downloaded, because {mailerName} could not    |
| `-' store local copies of the messages in your    |
|     "{inboxName}" file.                           |
|                                                   |
|     Check that you have enough disk space, and    |
|     that you have quit other applications which   |
|     may be accessing your local mail files.       |
|                                                   |
|                            ( Cancel ) (( Retry )) |
+---------------------------------------------------+

(Keyser, please note here the number of the bug which is preventing us from 
knowing exactly why the file cannot be written to.)

Comment 17

[Bradley Baetz]

> (Keyser, please note here the number of the bug which is preventing us from
> knowing exactly why the file cannot be written to.)

33451? ("convert mailnews to nsIFile") The real problem is that Keyser's patch
makes various commands check their return value, but the only thing which sets
it is the check that when opening, we end up with a real file. So its not that
we don't know why the error occured, its that we don't know that the error
occured at all, and, because we're using streams which don't have a way of
returning an error value, we can't.

There's a bug on full disks causing lost mail. For the moment, the only error is
"we couldn't open it for writing", or "before we started, there wasn't enough
disk space" (that check already exists).

Comment 18

[timeless]

|local copies|? sometimes this is destructive, and it is therefore not a copy.
|"{inboxName}" file| we shouldn't think of it as an inbox, and many people will 
be confused if we call it a file.

|     Check that you have enough disk space, and    |
|     that you have quit other applications which   |
|     may be accessing your local mail files.       |
This is bogus.

I shouldn't need to quit all of my applications that access 'local mail files' 
<bogus>.  In general, it should be possible to ask the os for a list of 
applications that have locked the files we care about.

We have to be concerned about permissions and quotas. Your dialog doesn't 
address this, and bbaetz explained the general problem [we have no idea what 
caused the failure].

Also, we can't retry.  For now, this is a fatal error.

Comment 19

[Bradley Baetz]

timeless: Does mozilla try to do any sort of file locking? If so, "close other
applications" may be valid, if it can't get the lock. If not, it probably
should. I don't know if its possible for in general to work out who has a file
lock - it could be another user, in theory. Or another copy of mozilla running
on another machine, with a network-mounted drive. Being told to close nfsd isn't
very useful :) 

We can't retry but, "Please fix this error and try again" (or words to that
effect) is valid - "Get new messages" can be manually retried by the user.

Getting more precise error detection (which is needed for bug 55814), would need
error checking at a lower layer, and flushing after each message. Is it possible
to prereserve filespace? The size is always given by the server, right? Is it
ever wrong (server bugs)? (followups for that -> 55814)

BTW, does movemail/IMAP have this same problem?

Comment 20

[Doron Rosenberg (IBM)]

r=doron for the patch, let's get this in for 0.8 and get the wording right
afterwards, ok?

Comment 21

[Keyser Sose]

*** Bug 65644 has been marked as a duplicate of this bug. ***

Comment 22

[Matthew T (active 1999-2002)]

> In general, it should be possible to ask the os for a list of applications that
> have locked the files we care about.

Sure. `Your messages from imaphost.foo.bar were not downloaded, because your 
local "Inbox" file is in use by the application "pine" and cannot be accessed by 
Mozilla.' But for now, we don't seem to be able to tell which app is causing the 
problem, or even if it is an app which is causing the problem.

> We have to be concerned about permissions and quotas.

I weighed up the probability of it being a permissions problem against the 
probability of the user being able to understand the best explanatory text I 
could work out for a permissions problem. I ended up chucking out any mention of 
permissions, on the grounds that the completeness wasn't worth the 
incomprehensibility. But I was careful not to claim that disk space and file 
locking were the *only* two possible causes of the problem.

As for quotas -- that's disk space.

> Also, we can't retry.

Why can't we just close the alert and call the get mail function again?

Revised text: `Your messages from {serverName} were not downloaded, because 
{mailerName} could not access your "{inboxName}" file.\n\nCheck that you have 
enough disk space, and that you have quit other applications which may be 
accessing your local mail files.'

Comment 23

[Brendan Eich [:brendan]]

'... other applications which may be accessing your local mail files.'

s/which/that/

for the defining clause.

/be

Comment 24

[Doron Rosenberg (IBM)]

approval keyword. btw, cnet was bitching about this bug in it's newest "bash
ns6" story...

Comment 25

[Scott MacGregor]

"Mozilla could not write the email to the mailbox. Make sure the file system
allows you write priveleges and enough disk space to copy the mailbox."

I'm wondering about the wording of this text message. "...the file system allows
you write priveleges...."

should this be something like "Make sure you have write priveleges on the file
system and that you have enough disk space to copy the mailbox."

Also, I don't believe you need to change the localMsgs.properties file for all
the different languages. Just change the english one. I believe the localization
folks will take care of updating all the other language string bundles to be
translations of the english one.

sr=mscott pending comments about the wording of the erorr message.

Comment 26

[Bradley Baetz]

I'd still prefer: "Mozilla could not write you message to your mailbox. This may
be because you do not have permission to modify your mail file, or there may not
be enough room available for you to do so.", implying "or something else could
have happened"

It doesn't make much of a difference though - I suspect that those two cases
cover most of the occasions this error would occur (and all of the ones
currently detected, AFAIK)

Comment 27

[timeless]

<collision>
I suggested passive because i couldn't think of a good way to write it in 
active., however i think this might work:

"Make sure you have write priveleges to the mail folder and that there is 
enough disk space to copy the mailbox."
or
"Make sure you have permision to modify the mail folder and that there is 
enough disk space to copy the mailbox."
modify/change
</collsion>

bbaetz's seems fine w/ this minor change:

qq(I'd still prefer: "Mozilla could not write you message to your mailbox. This 
may)=~s/you /a /

Comment 28

[Keyser Sose]

So are we all ok with...
"Mozilla could not write a message to your mailbox. This may be because you do
not have permission to modify your mail file, or there may not be enough room
available for you to do so."

As the error message?

Comment 29

[Brendan Eich [:brendan]]

Why is everyone still misspelling "privileges"?

/be

Comment 30

[Matthew T (active 1999-2002)]

Well, it doesn't tell you which of your local mail files can't be written to, it 
hard-codes `Mozilla' as the name of the mailer, it refers to `you' as if you are 
the computer program (remember, a process doesn't necessarily have the same 
permissions as the user running that process), it refers to `a message' when it's 
probably more than one message, it unnecessarily uses two different terms 
(`mailbox' and `mail file') for the same thing, it uses the enigmatic `room' 
instead of the obvious `disk space', the last five words (`for you to do so') are 
redundant, and (worst of all) it doesn't tell you what you can do to fix the 
problem.

Other than that, it's fine. :-)

Comment 31

[Keyser Sose]

*runs screaming* ok how bout this:

"Mozilla could not write a message to the mailbox. This may be because the
program does not have permission to modify the mailbox, or there may not be
enough disk space. Check the mailbox and try again."

As for, 
>the computer program (remember, a process doesn't necessarily have the same 
>permissions as the user running that process), it refers to `a message' when 

it *is* writing only one message when this is called, it knows nothing about any
other message, and all the messages written before that do not have a problem.

Comment 32

[Matthew T (active 1999-2002)]

If you get this error message once for every message when trying to download 
multiple messages, that's a bug in itself. But if not (if the fetch stops on the 
first error), then `a message' is counter-intuitive and should be removed.

Since it's dataloss, just check the dang thing in before 0.8 branches, and open a 
new bug to perfect the wording (I still haven't seen anything which I like better 
than my 2001-02-01 suggestion).

Comment 33

[Asa Dotzler [:asa]]

Is this going to make it in soon?  We're wrapping up 0.8 rsn and it would be
nice to see this included. 

Comment 34

[Blake Ross]

Fix checked in.  Someone can feel free to file a bug on improving the wording...

Comment 35

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

Keyser, please verify this when you're ready.  Thanks.

Comment 36

[Keyser Sose]

Verified Fixed. 

Opened bug 69627 for the error message problem.