Closed
Bug 62480
Opened 24 years ago
Closed 24 years ago
Will Download Messages Even If No Write Permissions on Inbox
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: brian, Assigned: mscott)
References
Details
(Keywords: dataloss, Whiteboard: would like for 0.8)
Attachments
(4 files)
1.76 KB,
patch
|
Details | Diff | Splinter Review | |
4.60 KB,
patch
|
Details | Diff | Splinter Review | |
2.27 KB,
patch
|
Details | Diff | Splinter Review | |
6.70 KB,
patch
|
Details | Diff | Splinter Review |
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!
Shortening Subject. I *think* this could be reporduced on a windows machine by setting the inbox to read-only in it's properties.
Summary: Will Download Messages Even If Write Permissions on Mail are NOT Available → Will Download Messages Even If No Write Permissions on Inbox
Comment 2•24 years ago
|
||
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•24 years ago
|
||
Whoops Marking NEW again
Comment 4•24 years ago
|
||
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.
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!
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.
Since still no action, nominating mozilla0.9 so someone reviews it.
Keywords: mozilla0.9
Comment 8•24 years ago
|
||
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.
OS: Windows 98 → All
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
Adding Updated Patch here in a second in mean time adding my name to CC: Sorry for the spam
Keywords: patch
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
patch fixes the dataloss for me on linux. Better wording is definitely necessary, however. ccing mpt
Comment 13•24 years ago
|
||
Comment 15•24 years ago
|
||
Comment 16•24 years ago
|
||
`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•24 years ago
|
||
> (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•24 years ago
|
||
|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•24 years ago
|
||
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•24 years ago
|
||
r=doron for the patch, let's get this in for 0.8 and get the wording right afterwards, ok?
Comment 21•24 years ago
|
||
*** Bug 65644 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
> 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•24 years ago
|
||
'... other applications which may be accessing your local mail files.' s/which/that/ for the defining clause. /be
Comment 24•24 years ago
|
||
approval keyword. btw, cnet was bitching about this bug in it's newest "bash ns6" story...
Assignee | ||
Comment 25•24 years ago
|
||
"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•24 years ago
|
||
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•24 years ago
|
||
<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•24 years ago
|
||
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•24 years ago
|
||
Why is everyone still misspelling "privileges"? /be
Comment 30•24 years ago
|
||
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•24 years ago
|
||
*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•24 years ago
|
||
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•24 years ago
|
||
Is this going to make it in soon? We're wrapping up 0.8 rsn and it would be nice to see this included.
Whiteboard: would like for 0.8
Comment 34•24 years ago
|
||
Fix checked in. Someone can feel free to file a bug on improving the wording...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Keyser, please verify this when you're ready. Thanks.
Comment 36•24 years ago
|
||
Verified Fixed. Opened bug 69627 for the error message problem.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•