Closed Bug 494415 Opened 16 years ago Closed 15 years ago

Removing an attached file from disk before sending mail causes hangup

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: kristo, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [needs followup bug for comment 14]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Nightlies until today

After attaching a file I removed it from the disk (zip file).
Then I tried to send the file and forgot to point to the 
newly zipped package.

TB tried continuously to send the file. After a while I ended TB 
and restarted it again. 

As expected the mail was in the outbox, but since I still didn't
know why seding it caused TB to hang again.

Reproducible: Always

Steps to Reproduce:
1. Attach a file
2. Remove the attached file from disk
3. Send the mail
Actual Results:  
Hangs while trying to send

Expected Results:  
TB should check the attached files when sending and
report any missing file ("The following files are missing.. Send the message anyway? yes/no")
Flags: blocking-thunderbird3?
(In reply to comment #0)
> As expected the mail was in the outbox, but since I still didn't
> know why seding it caused TB to hang again.

TB will only save to outbox if you are using send later or you have enabled the experimental send in background code. Is that what you are doing?
Keywords: qawanted
Exactly. Works fine.

But deleting the attachment is the problem. I tried this with 
another standard installation and TB also hung while trying
to send.

Tb doesn't seem to check the attached files "before" sending.
(In reply to comment #2)

Your case is attached file version of Bug 391190(attached mail case).

> Tb doesn't seem to check the attached files "before" sending.

Externally, it's partially wrong.
After attach operation, Tb reads attached file data upon first event in next:
  (1) "Draft Save" including auto-save, (2) "Send Later", (3) "Send".
But, internally, it's probably absolutely correct, because read of attached data when "Draft Save"/"Send Later"/"Send" is executed by same code.
(If draft save error occurs, Tb says "Send Error". It's already known problem.)
This Tb's behaviour produces problem like Bug 378046. Improvement of it is being discussed in Bug 378046.
Setting dependency to 378046 for ease of tracking.
Depends on: 378046
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1)
> Gecko/2008070208 Firefox/3.0.1
> Build Identifier: Nightlies until today
>
> Steps to Reproduce:
> 1. Attach a file
> 2. Remove the attached file from disk
> 3. Send the mail
> Actual Results:  

I get a nice message :

Sending of message failed.
Unable to open the temporary file /Users/ludo/Documents/gpbugzilla.xpi. Check your 'Temporary Directory' setting.

CPU usage is normal. That's on mac. Let see what happens on windows. Same goes on Win32.

Kristo are you running an anti-virus ? if so which one ?

this looks WFM for me.
Well I'm running ESET, but I've never seen this error.
The problem only occurs here when I remove the attached
file from disk BEFORE finally sending the mail.

TB simply does not check if the attached files are still
there or not and seems get stuck in a loop  while sending.
Works for me in Thunderbird 2, and works exactly the same way in Thunderbird 3.0b2, with Windows XP.  A nicely formatted error message appears telling me about the problem if the file is deleted before sending.
Kristo if you disable Eset (nod32 ?) - do you still see the issue ?
why not copy the file (if too big) to memory in order to be able to send PDFs and other small files even when they've been inadvertently deleted?
ESET was switched off at that time. Since I'm havng problems
with AutoIt scripts I have to turn it off every time I'm doing
some work.

Another thing comes to my mind. Is there a way to limit the 
attachment size for one mail? Or even better additionally to
set a limit per recipient? We always have problems with the
mailbox sizes of some recipients...
Denying blocking given the bug's current state.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
WFM here. No hangs and similar message that is show in comment #4.

We can close as WFM I think.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100322 Lightning/1.0b2pre Lanikai/3.1b2pre ID:20100322032145
Kristo do you still encounter the issue ?
Keywords: qawanted
Whiteboard: closeme 2010-05-12
RESOLVED INCOMPLETE due to lack of response to previous comment. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Blocks: attach-paradigm-fail
No longer depends on: attach-paradigm-fail
(In reply to WADA from comment #3)
> (In reply to comment #2)
> 
> Your case is attached file version of Bug 391190(attached mail case).

Wada, do we have a bug about "attached file version of bug 391190", i.e. "Already attached files lost when original attachment files are moved/deleted"?
Flags: needinfo?(m-wada)
Internal URL is different.
  Attached mail : mailbox:.../MboxName%3Ennn (%3E = ">")
  Attached file : Initially, file: URL
I don't know whether file: URL is converted to mailbox: URL or not when draft save.

If you believe "initially file: URL case === mailbox: case", close as dup, please.
Flags: needinfo?(m-wada)
Duping to bug 516373 may be better.
Well, this bug is already resolved, but I was thinking of opening a new bug for the dataloss scenario of "attached file initially referenced as URL to original file, then moved/deleted before conversion into mime part" (somewhat related to but not the same as bug 378046).

That's different from bug 516373 which only seeks to fix the inappropriate error message which occurs for that scenario, but not the underlying problem. Bug 516373 is much easier as a bandaid-fix than fixing the underlying problem, so it's better to keep them separate.
Whiteboard: closeme 2010-05-12 → [needs followup bug for comment 14]
It sounds for me that phenomenon reported to Bug 516373 and comment #4 is;
1. Upon save as draft or send, Tb tries to copy "attached file represented in file: URL" to temporary file, and assigns temporary file name(call TempX).
2. Tb tries to copy "attached file represented in file: URL" to TempX.
3. Because "attached file represented in file: URL" is alreay deleted or moved by user, Tb failes to create TempX.
4. Even though step 3, Tb tries to generate subpart for attached file from non-existet TempX file, then error message of "TempX is not found" is shown.

What do you call "bandaid-fix for bug 516373"?
If correct error message of "requested/original attachment file is not found", I think it's sufficient, because following is already well known in Bug 378046.
  "immediate attached file copy" is needed to avoid "attachment file
  is not found" which is produced by delete/move of original file by
  user after "attach file" operation at mail composition window.
(In reply to WADA from comment #18)
> It sounds for me that phenomenon reported to Bug 516373 and comment #4 is;
> 1. Upon save as draft or send, Tb tries to copy "attached file represented
> in file: URL" to temporary file, and assigns temporary file name(call TempX).
> 2. Tb tries to copy "attached file represented in file: URL" to TempX.
> 3. Because "attached file represented in file: URL" is alreay deleted or
> moved by user, Tb failes to create TempX.
> 4. Even though step 3, Tb tries to generate subpart for attached file from
> non-existet TempX file, then error message of "TempX is not found" is shown.

I can't verify right now, but that sounds like a plausible, precise, and excellent analysis to explain phenomenon of "unhelpful" (but probably technically correct) error message.

> What do you call "bandaid-fix for bug 516373"?
> If correct error message of "requested/original attachment file is not
> found", I think it's sufficient

Fixing Bug 516373, i.e. only correcting the error message to be more helpful (and/or avoid pointing non-existant temp-file when original file is not available for copy to temp-file) provides a bandaid-fix for current double problem in cases of "attachment not found" when original moved/renamed/deleted (problem 1: always or potential datalosss; problem 2: useless error msg).

Arguably, correct & helpful error msg is a working (but ux-violating/poor/inefficient) fix for certain cases of original *moved/renamed* if still within reach of user and unaltered original, user can then re-attach. Note that dataloss can still occur even for *moved/renamed*:
- user correctly expects that TB is holding snapshot copy of initial file status after attaching; then changes file contents after attaching but before TB creates tmp-file; original file contents are gone when sending -> dataloss, violation of privacy when wrong/unexpected data of modified file are sent (along bug 378046)
- depending on circumstances, e.g. file from usb-flash, interrupted compositions over timespan, file might no longer be accessible from (removable/remote) media to which it was moved after attaching
- original file might be irretrievably altered without user intervention, e.g. logfiles and other dumps.

However, correct error msg does not fix dataloss scenario of "original attachment *deleted* by user / inaccessible for user" after attaching and before TB created tmp-file.
a) dataloss of attached *msgs etc. from inside TB's mailfolders*: bug 391190
b) dataloss of attached *files* from outside TB: bug 722094 (that's the one I was looking for in comment 14).

These bugs are more focussed on presenting problems than solutions. General solution of immediate snapshot is clear (as discussed in bug 378046 and bug 722094), but technical details might differ for files from outside vs. data from inside TB.

> because following is already well known in
> Bug 378046.
>   "immediate attached file copy" is needed to avoid "attachment file
>   is not found" which is produced by delete/move of original file by
>   user after "attach file" operation at mail composition window.

Yes. delete/move/*rename*

So it's all sorted and on record :)

Btw, complete solution is to provide
"immediate snapshot" (required as default; no dedicated bug yet*) AND 
"attach when sending" feature (optional, bug 722929).

*) The only thing I still want to do is to extract "immediate snapshot of external files" solution part from lengthy bug 378046 into it's own solution-focussed bug. But who will fix it??
(In reply to Thomas D. from comment #19)
> *) The only thing I still want to do is to extract "immediate snapshot of external files" solution part
> from lengthy bug 378046 into it's own solution-focussed bug.

If so, I think "crispy new bug opened by you for symptom of this bug and Bug 516373" is best for it.
FYI.
As you already know, bug 722094 exists for "attachment file content change by user after attach operation at composition window"(original case).
Bug summary of that bug is "attachment file might change or disappear before send". So, that bug surely covers "delete/move/rename attachment file" case.
You need to log in before you can comment on or make changes to this bug.