473336 - SeaMonkey Download Manager opens in one profile but not in another

Status: RESOLVED WONTFIX

(SeaMonkey :: Download & File Handling, defect)

Description

[VRN]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14

I have two profiles set up in SeaMonkey (under the same Windows account).  Each profile is stored on a different/separate harddrive partition.  The Download Manager (DLM) of the second profile will not load when attempting to invoke it from the Tools menu nor when a download starts.  However, if I switch profiles to the older/first profile (via Tools/Switch Profile), the DLM opens up in the first profile, normally, as it should.  Then, when I switch back to the second profile (via Tools/Switch Profile) and invoke the DLM (again, from the Tools menu or when a download begins), it opens up just fine, except that it has a list of files downloaded from/into the first profile.  Both profiles execute the same SeaMonkey program code.  How does the DLM get invoked/executed from within SeaMonkey?  

Reproducible: Always

Steps to Reproduce:
1. 
2.
3.



The problem seems to be specific to this machine.  It seems to have begun about the same time I deleted some obsolete profile folders from the C: drive for the second profile, which has always been located on another drive.  Attempts to restore those files have not resolved this issue.  The pointer for the DLM in the second profile seems to be pointing to an unresolved folder.  What pointer is this, where is this pointer located, and how can it be modified to point to the correct folder?

Comment 1

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v2.0a2 ?

Comment 2

[VRN]

Ok, I tried a fix to resolve this issue and it worked - for a little while.

What I did was I went into the mozilla folder of the second profile and deleted all of the DOWNLOADS.RDF files.  Then I clicked on Tools/Download Manager and a new, clean, empty window opened up.  I was then able to do downloads as before.  However, it ceased to load this afternoon for some reason.  So I again went into the mozilla profile folder and this time, I double-clicked on the DOWNLOADS.RDF file.  Seamonkey tried to open it but instead displayed this error message:

XML Parsing Error: not well-formed
Location: file:///C:/Documents%20and%20Settings/Account%201/My%20Documents/Z%20Platform%202/ho3ppmmy.slt/downloads.rdf
Line Number 1, Column 1:

I don't know if that is significant information, or not, but there it is.  

In order to get the DLM functioning again, I again deleted the DOWNLOADS.RDF file, thus losing my download history.  

Obviously, this is still an on-going issue.

Comment 3

[VRN]

(In reply to comment #1)
> Can you reproduce with SeaMonkey v2.0a2 ?

I looked at downloading v2.0a2 but decided not to after I read the warning about it not yet being completely stable for daily use.

Comment 4

[lenochod]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14

Tested in clean profile and is show on both profile well files.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090122 SeaMonkey/2.0a3pre

Works for me.

Comment 5

[VRN]

(In reply to comment #4)

I'm sorry, but that comment makes no sense.  If you speak English at all, then please use proper grammar and syntax. Otherwise, you are just wasting time for both of us.  Thanks for the attempt.


> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081204
> SeaMonkey/1.1.14
> 
> Tested in clean profile and is show on both profile well files.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090122
> SeaMonkey/2.0a3pre
> 
> Works for me.

Comment 6

[Philip Chee]

This is a known problem. Corruption of the downloads.rdf file prevents the download manager window from opening. This is "fixed" in SeaMonkey 2.0b1 since we now use a sqlite file to store the download data. This problem will not be fixed in SeaMonkey 1.1.x since that branch will only accept security and stability fixes.

Your currently workaround is to delete the existing downloads.rdf file.