The beta builds (8.x) of Eudora are free software.  If this bug can be reproduced with them, source code availability will probably make it much easier to fix in wine.

@Robert Millan: Eudora 8 is in no way related to Eudora 7.1.0.9.  It is an adaptation to Thunderbird.

Fixing summary and product, adding download link.

I couldn't get Eudora to work with my POP3 mailbox. Please retest in current (1.1.12 or newer) wine.

Wine version 1.1.20, Ubuntu 9.04, Eudora 7.1.0.9
The problem still exists. Trying to open any attachment from any email results in no action, no file opened. I have to go to a file manager to open the attachments.

Please don't change the version field.

is this still an issue in 1.3.20?

just tried to test with wine 1.3.20, but couldn't open any e-mails. just got an empty window and finally eudora crashes with an "unhandled exception page fault".

I'll add an error log as soon as I have time to repeat my test.

Created attachment 35365 [details]
Trying to open a text file attachment

The same error happens regardless of the filetype

I can confirm this bug. Using Linux Mint 10, Wine version wine-1.2.2

If i try to open ANY attachment, I get an error dalog "There is no Windows program configured to open this type of file."

This happens regardless of filetype, be it registered (like .TXT, .BMP) or not (.PDF, .XLS, etc) within wine. All files have their mime types correctly configured in my system (outside wine)

This happens for attachments both received AND sent.

Also, RMB > "Send to Browser" does not work (same message)

The *only* thing that works is clicking an URL (http://www.xxx.com). That correctly opens my FireFox outside Wine.

I've spent the last 20+ hours carefully studying WINEDEBUGGER=+relay 1.3GB logs, and I've found the bug! And a way to workaround this issue that has been tormenting me for the last 3 years! :D

The culprit (I guess) is this line:

0009:Call advapi32.RegQueryValueW(80000000,0033b9a0 L"txtfile\\shell\\\\command",0033ada0,0033a52c) ret=7e9a3c04
0009:Ret  advapi32.RegQueryValueW() retval=00000002 ret=7e9a3c04

Notice the (weird) absence of "Open" in "txtfile\\shell\\\\command". The function, obviously, returns 0x2 (ERROR_FILE_NOT_FOUND)

So if I duplicate the registry "command" key right under shell (instead of under "open"), the attachment opens perfectly!

Right now I'm documenting all the steps. I dont know if this is the best and/or only solution, so I would *really* appreciate a closer help by *any* developer familiar with Wine.

Can any one contact me for further investigation? its " wine (a.t.) rodrigosilva (d.o.t) com " (yes, trust me, it works, i own the domain)

Thanks!

Created attachment 35382 [details]
Relay dump showing Eudora trying to open the file, and Messagebox saying it can't, with a possible workaround

- In order to minimize API calls and considerably reduce the log (original was 1.3GB!), Eudora was previously set to File > Work Offline. Also, I've sent myself an email with several attachments. The received email was already opened and maximized, all other emails and mailboxes were closed.

- Ive launched Eudora with the command:

	env WINEPREFIX="/home/rodrigo/.wine" WINEDEBUG=+relay wine C:\\Program\ Files\\Qualcomm\\Eudora\\eudora.exe 2> dump.txt

- As suggested by http://wiki.winehq.org/DebugChannels , the most frequent (or distracting) calls were excluded in Registry HKCU\Software\Wine\Debug\RelayExclude. Hope none are relevant to the bug. They were:
	KERNEL32.SetLastError;KERNEL32.GetLastError;KERNEL32.FlsGetValue;ntdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;ntdll.RtlFreeHeap;ntdll.RtlAllocateHeap;KERNEL32.TlsGetValue;KERNEL32.GlobalUnlock;KERNEL32.GlobalLock;KERNEL32.lstrlenA;user32.CallWindowProcA;user32.SendMessageA;KERNEL32.lstrcpyA;user32.GetWindowLongW;KERNEL32.GetTickCount;

- Eudora was launched, the test email already showed up, maximized. The only operations done were:

	- Click the "teste.mdb" attachment (MDB was not associated in Wine). Used as a lower bound "flag" to trim the log
	- Click the "carro.txt" attachment (TXT associated with notepad). The actual test case
	- Click the "teste.mdb" attachment again, as an "upper bound" to trim the log
	
- The 3 operations showed a "There is no Windows program configured to open this type of file." MessageBox

- Log was trimmed: Deleted everything before the first MessageBox (from the 1st click on teste.mdb), and after the second MessageBox (log went from 25MB to ~6MB). Then further trimmed to ~750K by deleting everything before the first occurrence of "carro.txt"

- Relevant log entries, in my opinion, are the very last ones:

0009:Call advapi32.RegQueryValueW(80000000,0033b5dc L".txt",0033b9a0,0033bbac) ret=7e9a6c7a
0009:Ret  advapi32.RegQueryValueW() retval=00000000 ret=7e9a6c7a
0009:Call advapi32.RegOpenKeyExW(80000000,0033b9a0 L"txtfile",00000000,02000000,0033a528) ret=7e9a3b66
0009:Ret  advapi32.RegOpenKeyExW() retval=00000000 ret=7e9a3b66
0009:Call advapi32.RegCloseKey(000000d4) ret=7e9a3bbc
0009:Ret  advapi32.RegCloseKey() retval=00000000 ret=7e9a3bbc
0009:Call advapi32.RegQueryValueW(80000000,0033b9a0 L"txtfile\\shell\\\\command",0033ada0,0033a52c) ret=7e9a3c04
0009:Ret  advapi32.RegQueryValueW() retval=00000002 ret=7e9a3c04
0009:Call shlwapi.PathIsDirectoryW(0033e464 L"D:\\Arquivos\\Email\\attach\\carro.txt") ret=7e9a8a26
0009:Call KERNEL32.GetFileAttributesW(0033e464 L"D:\\Arquivos\\Email\\attach\\carro.txt") ret=7eb47738
0009:Ret  KERNEL32.GetFileAttributesW() retval=00000020 ret=7eb47738
0009:Ret  shlwapi.PathIsDirectoryW() retval=00000000 ret=7e9a8a26
0009:Call shlwapi.PathIsURLW(0033e464 L"D:\\Arquivos\\Email\\attach\\carro.txt") ret=7e9a8e68
0009:Ret  shlwapi.PathIsURLW() retval=00000000 ret=7e9a8e68
0009:Call user32.LoadStringW(7e950000,000000a4,0033abb0,00000800) ret=7e9a3ac2
0009:Ret  user32.LoadStringW() retval=00000041 ret=7e9a3ac2
0009:Call user32.MessageBoxW(000100c4,0033abb0 L"There is no Windows program configured to open this type of file.",00000000,00000010) ret=7e9a3a84

The "txtfile\\shell\\\\command" suggests that Eudora, somehow, is not accessing the right path (it should be ""txtfile\\shell\\open\\command"). So duplicating the "command" key entry directly under "shell" fixes the problem, but i think this non-standard workaround misses the point, since it works perfectly in XP.

I can see this issue in wine 1.3.22, and no longer in wine 1.7.11 (attachment is opened correctly). Assuming fixed, if anyone is still able to reproduce feel free to reopen.

Closing bugs fixed in 1.7.12.