240644 - Hangs if last attachment was on a path that does not exist anymore

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Sepehr Kiani]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114

This is a mobile system with servers mounted using autofs. If I'm at one site
and create an attachment of a file on a path that is on one of my server mounts,
then next time I go to make an attachment it points to that same path (this is
useful behavior).  But now if I go to a different site where my server is not
present that path is no longer present. If I now go to make an attachment
mozilla hangs indefinitely the instant I select add attachment. No there is no
way to make an attachment until I get back to the site with where the server is
present and the path is live again. I have only observed this problem with nfs
mounted shares using autofs, it might also occur with smb file system as well as
conventional mounting. I also don't know if it is a problem that affects more
than just the email client.

Reproducible: Always
Steps to Reproduce:




Expected Results:  
The software should try the path, if it doesn't respond then it should move back
to the default path (user home path).

Comment 1

[Thomas B. Rücker [account mostly dormant]]

Version 1.0 (20041206)
Windows XP SP2 Build 2600

This is a IBM T42p. Quite mobile too. Seems i attached a file from a SMB-share
last time. Now it b0rks every time i press "attach".

Reproducible: Always
Steps to Reproduce:
1. Start TBird
2. Open Message Compose Window
3. Press Attach
*poof*

x-plattform-bug?

Comment 2

[Martin Creutziger [:MMx]]

looks like this bug *really* exists (I watched Thomas crash TBird with my own
eyes). 
Will do some testing with SeaMonkey-trunk and/or TB-trunk soon.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
What will happen when "ls" or other command to list resources is executed for
the non-present path?

(In reply to comment #1)
What will happen when "dir \\server_name\resource_name\dir_name" for not mounted
SMB shared resource from MS DOS prompt?

Comment 4

[Thomas B. Rücker [account mostly dormant]]

(In reply to comment #3)
> (In reply to comment #0)
> What will happen when "ls" or other command to list resources is executed for
> the non-present path?
--------8<-------------
dk0td:/media# ls /media/cdrom
ls: /media/cdrom: No such file or directory
--------8<-------------
> (In reply to comment #1)
> What will happen when "dir \\server_name\resource_name\dir_name" for not mounted
> SMB shared resource from MS DOS prompt?
--------8<-------------
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Dokumente und Einstellungen\dm8tbr>dir \\192.168.0.227\C$\lala
Der Netzwerkpfad wurde nicht gefunden.

C:\Dokumente und Einstellungen\dm8tbr>
--------8<-------------
though executing this takes around 1-2min.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
When MS Win and SMB, will "mounting as network drive(assign drive letter)" be a
workaround?
(1) NET USE X: \\server_name\resource_name (password and so on.)
(2) Attach file on X: drive to a mail
(3) Make the server unaccessible. (Keep mounted as X:)
(4) Try to attach file on X: again.

When UNC path on MS Win or mounted resource on Unix, possibly problem like "DNS
cache not updated"...
Can restart of Thunderbird be a workaround in original problem of comment #0?  

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[WADA:World Anti-bad-Duping Agency]

DUPed Bug 278914 says ;
When Thunderbird hang due to unaccessible remote resource after successful
attach of a file such as \\192.168.1.1\folder\a.txt,
(a) No success even after reboot
(b) Had to finally edit the prefs.js file in my document and settings folder
    and get rid of any lines that mention the networked folder

Why timeout nor error doesn't occur even after reboot, when Thunderbird requests
unavailable remote resource?
Timeout occurs but Thunderbird cannot handle the timeout?
Socket request? If yes, Bug 278144 can be a related bug.
> Bug 278144 : Support socket i/o timeouts 

Comment 8

[WADA:World Anti-bad-Duping Agency]

Bug 229924 reported same problem when unavailable LAN resource.
>Bug 229924 : Mail hangs when attaching to/from unavailable local network locatio

Similar(different though) situation was reported by Bug 142664.
> Bug 142664 modal dialog asking for a floppy/removable media cannot be canceled
Bug 142664's case sounds;
 (1) Use A: (Floppy disk. by download manager in this case)
 (2) Remove the Floppy disk.
 (3) Try to use download manager again
 (4) Download manager requests "A:" drive as last accessed resource
 (5) Dialog appeares and ask to maunt A: (by Operating System)
 (6) User cancel mount -> error -> Go to (4)
If same scenario can be applied, even if timeout can be detected for network
resource, forever retry will occur...

Comment 9

[WADA:World Anti-bad-Duping Agency]

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

Comment 10

[WADA:World Anti-bad-Duping Agency]

Thunderbird & Mozilla Mail&News saved last used directry for attachment in next
entry of prefs.js.
> user_pref("mail.compose.attach.dir", "C:\\TEMP");
So next can be a workaround, although restart of Thunderbird/Mozilla is required
when problem occured.
(1) Add mail.compose.attach.dir entry in user.js file in profile directry.
    user_pref("mail.compose.attach.dir", "C:\\TEMP");
(2) Restart Thunderbird/Mozilla(whole Mozilla, not Mail&News only)
    when problem occured.

Note-1:
 "C:\TEMP" will be always used as candidate of directry when first trial of
 mail attachment after restart, because last used directry is forced to
 "C:\TEMP" on every restart.
Note-2:
 prefs.js entry used by Download Manager is different. 
    user_pref("browser.download.dir", "C:\\TEMP");
 (Sorry but I don't know whether this is used by Thunderbird or not.)

Comment 11

[WADA:World Anti-bad-Duping Agency]

Bug 202735 and Bug 257052 also reported similar problem, although
product/component is different.

Comment 12

[R.K.Aa.]

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

Comment 13

[R.K.Aa.]

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

Comment 14

[Neil J. McLeish]

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

Comment 15

[David :Bienvenu]

Windows seems to be hanging in the commdlg code. I tried this with Word and it
was much better behaved - it timed out after 20-30 seconds, and then brought up
the picker on a local directory. I got the impression that it was trying to
verify it could access the last accessed directory before bringing up the common
dialog. I wonder if that times out much more quickly?

Comment 16

[David :Bienvenu]

Attachment: possible fix

this is a bit of a stab in the dark. It did much improve the problem I was able
to recreate, however. I attached a file from a shared directory on another
computer, and then took the other computer off the network. Then I brought up
the attach dialog again - it hung for several minutes. With this patch, it
hangs for about 30 seconds, before bringing up the cwd in the browser.

I don't know if this will break things like password prompting for an existing
share, if this is the first access, or what...

Comment 17

[David :Bienvenu]

cc'ing Darin, since it's sort of a windows networking question :-)

Comment 18

[Scott MacGregor]

Comment on attachment 189098 [details] [diff] [review]
possible fix

Pav is probably the closest thing we have to an owner for this widget. I also wonder if we should be doing something similar for all ofour file picker implementation or is this hang on Windows only, hence we only need to fix it on windows only.

Comment 19

[WADA:World Anti-bad-Duping Agency]

Changing to Core/File handling.

Comment 21

[Adam Guthrie]

Maybe biesi has some thoughts about David's patch. 

Comment 22

[Helmut Auer]

Hi,
I'd vote for David's patch (much better than nothing). In the moment I am forced to use IE or opera to attach a file to my webmailer because the only workaround is a new OS Installation, and that's not acceptable :)

Comment 25

[WADA:World Anti-bad-Duping Agency]

Bug 303675 was fixed, and Bug 2570528(then dup'ed bugs) is closed as DUP of it.
And Bug 1426464(then dup'ed many bugs) is closed as WORKSFORME.
Does problem still remain?

Comment 26

[WADA:World Anti-bad-Duping Agency]

Should be Bug 257052. Sorry for spam. 

Comment 27

[WADA:World Anti-bad-Duping Agency]

Should be Bug 142646. Sorry for spam again.

Comment 28

[WADA:World Anti-bad-Duping Agency]

To David Bienvenu(Assigned To: person):

Bug 303675 was already fixed, and problem seems to be WORKSFORME already. 
Do you think your patch will still be needed?

Comment 29

[David :Bienvenu]

Comment on attachment 189098 [details] [diff] [review]
possible fix

Roc, is there someone better to do a module owner review for this?

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 189098 [details] [diff] [review]
possible fix

Ere Maijala, maybe.

Comment 31

[David :Bienvenu]

Comment on attachment 189098 [details] [diff] [review]
possible fix

Ere, can you do a module owner review for this? thx

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

+      initialDir = NS_LITERAL_STRING(".");

initialDir.AssignLiteral("."); ?

Comment 33

[David :Bienvenu]

sure, I can make that change...if I can get a review from Ere, I'll make that change and attach a diff before checking in...

Comment 34

[Ere Maijala (slow)]

Comment on attachment 189098 [details] [diff] [review]
possible fix

Sorry for the slow response.

Weird problem. The fix seems ok, although if mDisplayDirectory doesn't exist and mLastUsedUnicodeDirectory has also been deleted, wouldn't it get a non-existing path again?

Comment 35

[David :Bienvenu]

fix checked in - I did ultimately remember bisi's comment, but after I checked in the first time, so I checked it in again with his suggestion.

Re Ere's comment, I think you're right, though I'm not sure how likely that scenario is compared to the scenario that's fixed.

Comment 36

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #34)
> Weird problem.
It's problem of Bug 394209, isn't it?

Comment 37

[Steve England [:stevee]]

It looks like this caused bug 395053

Comment 38

[David :Bienvenu]

yes, I'm going to back myself out, unless I can figure out a quick fix.

Comment 39

[David :Bienvenu]

I backed out my changes locally - it didn't seem to make any difference...

Comment 40

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #39)
> I backed out my changes locally - it didn't seem to make any difference...

At least Bug 394910 is still open. Please be careful in testing.

(In reply to comment #39)
> yes, I'm going to back myself out, unless I can figure out a quick fix.

Without your patch, it was very hard to find Bug 394209 & Bug 394910 (not exposed). And Bug 394910 is still open. 
If you'll back out, detection of problem like Bug 394209 & Bug 394910 becomes difficult. 
And "fall back to 'work folder'" itself is not wrong(rather proper), as I wrote in Bug 395053 Comment #6, and as Gavin Sharp says in Bug 394209 Comment #13. 
  
David, I think you'd better to wait for a while before back out, although I agree with you on back out.

Comment 41

[David :Bienvenu]

backed out - we'll see if the other bugs disappear.

Comment 42

[WADA:World Anti-bad-Duping Agency]

FYI.
When I tested with Tb trunk 8/22 build & 8/27 build(before your patch), and when all of xxx.dir settings was non-existent directory, "last directory" was offered. (Probably latest one in MRUList in OpenSaveMRU\* or OpenSaveMRU\<ext> when MS Win)
  (Case-A) All path related settings is non-existent directory  
           user_pref("browser.download.dir", "\\\\AAA\\AAA");
           user_pref("browser.download.downloadDir", "\\\\BBB\\BBB");
           user_pref("mail.compose.attach.dir", "\\CCC\\CCC");
           user_pref("messenger.save.dir", "\\\\DDD\\DDD");
  (Case-B) No above path related settings (just after profile creation)
And, when the "last directory" was also non-existent (I renamed directory), "Work Folder"="Current Folder" was offered.

Comment 43

[WADA:World Anti-bad-Duping Agency]

Bug 395053 was for regression in "File->Open" ("Open Saved Message" when Tb). 
Sorry for my confusion.

Comment 44

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #41)
> backed out - we'll see if the other bugs disappear.
Bug 395053 disappeared by your back out. 

Comment 45

[WADA:World Anti-bad-Duping Agency]

To David Bienvenu:

Have you found a way to make file picker lot faster (you say so 
in your comment in the patch) when non-existent directory for save/attach, without breaking File->Open/No-last-used-directory case?
Do you still think that "making file picker lot faster when non-existent directory" is required and mandatory?

Comment 46

[Gregor]

Seems to be the same/a similiar problem: if you try to save a mail (ctrl+s) and enter \\server\folder\savename save dialog hangs if \\server\folder\ isnt't avaiable.

Thunderbird Version 2.0.0.9 (20071031)

Comment 48

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #47

Magnus, this bug's original issue(comment #0) was already fixed by patch for Bug 303675(see comment #28 and Comment #42). And, many similar bugs were already closed by fix of Bug 303675.
Reason why this bug's status==REOPENED is;
 1. Patch for Bug 303675 was landed around 2005-08-08(landed also on 1.8b4). 
 2. Patch for this bug after fix of Bug 303675 produced regression of Bug 395053.
 3. So the patch for this bug was backed out, and changed to REOPENED status.

I believe Comment #46 and Bug 489486 should be manipulated in separate bug, because;
Bug 429827, Bug 443006 etc. are newly generated, and "fall back algorithm" seems to have been changed, and other issues(e.g. "lastdir" is used and asked location even though "always save to specified directory" is chosen) seems to have been generated.

Comment 49

[Magnus Melin [:mkmelin]]

WADA: feel free to change as appropriate.
So this bug is WFM?

Comment 50

[WADA:World Anti-bad-Duping Agency]

> So this bug is WFM?

I think original problem(comment #0 and some other comments) are WFM(probably fixed by Bug 303675). However, this bug was re-opened by Assigned To: person of this bug and no answer to comment #45. An user like me can do nothing.

Comment 51

[WADA:World Anti-bad-Duping Agency]

I've re-opened Bug 489486(for Tb 2.0.0.21).
Gregor(comment poster of Comment #46 for Tb 2.0.0.9), watch Bug 489486.

Comment 52

[WADA:World Anti-bad-Duping Agency]

When I tested Comment #42, final fall-back directory was "Work Folder"="Current Folder". But, as I wrote to Bug 489486, fall-back directory of Tb2 seems MRU(most recently used) directory if MS Win.
Magnus Melin, we seem better to manipulate this kind of issues in separate bugs, for Tb 2 and for Tb trunk, because internal design of fall back/prefs.js entry usage seems to have been changed.

Comment 53

[WADA:World Anti-bad-Duping Agency]

I think this bug's original problem(bug summary, comment #0) is already fixed by Bug 303675. Closing as FIXED with [fixed by Bug 303675] in white board. If it's wrong, and if "performance improvement in fall back" is still required, please re-open.