First: This is not Bug 171441! I read about this bug in a Newsgroup and then asked a few questions so that i can fill this bug. When the user clicked on a Downloadlink, the error-message "c:\docume~1\jlemay~2.NJM\locals~1\temp\<filename> could not be saved, because the source file could not be read." comes up. <filename> is the random string, but it does not have any file ending, for example "efxzdj.". When the user right clicked on a link and then selected "Save Link Target As..." the file picker came up (this did not happen when the user directly clicked on a link). But when you clicked on OK the file picker closed and nothing further happened. The user installed Mozilla in a clean folder. After he renamed the compreg.dat to compreg.old and started Mozilla all worked again. I'll attach the compred.old
Attachment #121926 - Attachment description: Corrupted(?) compreg.dat → Corrupt(?) compreg.dat
Ah, forgot something important: He used Mozilla 1.3
I am using Mozilla 1.4a on Windows XP. I am also seeing this problem. I am not able to save any attachments. When I try to save an attachment, I get the following error msg: C:\DOCUME~1\xyz\TEMP\6ecekzit.jpg could not be saved, because the source file could not be read. Try again later, or contact the server administrator
I am using FlashGet http://www.flashget.com/ - after some time FlashGet came up with 20 windows, i think this is the count of links i tried to open in Mozilla. --> Mozilla 1.4RC1 ;-( Have to download files in the Internet Explorer!!! ;-(((
I'm using 1.4b on Windows XP. I had a problem also but didn't get the error message ("...source file could not be read...") until I added "application/octet-stream" to the helper apps. Somehow the MIME types got screwed up and once I added octet-stream to them I started getting this error. My problem was solved by renaming compreg.dat.
*** Bug 203446 has been marked as a duplicate of this bug. ***
This bug appears in 1.4RC1 - but is not present in 1.3.1.
*** Bug 208832 has been marked as a duplicate of this bug. ***
i'm seeing this also on Win XP and mozilla 1.4b Erasing compreg.dat solved the problem.
Due to messages about this bug being in 1.4RC1, in particular comment #7, asking for 1.4blocker. Although, I'm curious as to why the reporter says this isn't the same as Bug #171441, as it appears to me to be a regression on that bug. Anyway, over to drivers to decide what happens next.
*** Bug 209255 has been marked as a duplicate of this bug. ***
If this would be a regression, i think there would be much much more dupes. I don't really know if this is a regression, sounds like one, but i'm not really sure...
I have the same problem, deleting the compreg file solved the problem for a day, but then it stopped working again.
deleting compreg.dat is no real solution! please fix this asap! pages with download control scripts like doom9.org cannot be used because of this bug.
*** Bug 204433 has been marked as a duplicate of this bug. ***
I got this same error, it seems that the download manager cannot handle larger files. I only got 2 or 3 % into a 600MB download(it's legal, really) from a source that had no problems for Internet Explorer to take all day to finally finish. It might have something to do with the size of the space allocated for the temporary file.
*** Bug 211785 has been marked as a duplicate of this bug. ***
very nasty bug, since i simply did not know where to start .. renaming the compreg.dat fixed it, thank you!
I also have some similar download problems with Win2k SP4. I often have to click some link twice if I want to download something (e.g. I wan't to watch an MPEG1-movie in mplayer2) and even after clicking twice I won't have any download window although the file is downloading. That is irritating. In some cases (mainly related with zip-files) I get that "C:\DOCUME~1\***\LOCALS~1\TEMP\*** could not be saved, because the source file could not be read." I'm using the computer as an Administrator, so it can't be because of permissions. I wan't to be able to download files without IE. :)
*** Bug 207767 has been marked as a duplicate of this bug. ***
Also had this bug regular. I´m using Mozilla 1.4 _final_ on WinXP SP1. The bug occurs just about once a day, only deleting compreg.dat fixed it for a few hours. Now, the bug doesn´t occour for about a week, since I updated from JRE 1.4.1_03 to JRE 1.4.2. I know, this doesn´t make much sense and could only be a bad coincidence, but who knows...
I am using Realease 1.4 final and Win XP SP1. I have the same problem. It does go away for 2-3 weeks of regular usage when I reinstall Mozilla on top of the previous installation (the same version of Mozilla). It proves, however, to be one of the most annoying bugs I've come across since it is also happening by opening file types that are viewed in the browser (such as JPGs). There have been times that I was reading a long article in a web page, and when I needed to click on a link to see at the diagram, I realised that I had to re-install Mozilla.
There might be a dupe: bug 213076 I also cannot directly open email attachments - however, saving them is possible.
I found that by switching the browser's theme to Classic or (sometimes) Modern and attempting to download something it usually gets fixed, after this you can switch back to the theme that you had before, and download as you regularly would.
*** Bug 215568 has been marked as a duplicate of this bug. ***
Whiteboard: WORKAROUND: possible workround see comment #24 or comment #9
*** Bug 208608 has been marked as a duplicate of this bug. ***
*** Bug 216595 has been marked as a duplicate of this bug. ***
*** Bug 215198 has been marked as a duplicate of this bug. ***
*** Bug 218081 has been marked as a duplicate of this bug. ***
*** Bug 218173 has been marked as a duplicate of this bug. ***
Darin, Dougt, this is gathering dupes at a pretty high rate. Can you guys spare any cycles to look into this?
The things I've tried to download (Pictures from Kmart/Kodak site, musical bits from Amazon, and something else) came down OK in Netscape 7.0 and in some recent version of MS Internet Explorer.
The type of file that is being downloaded doesn't matter at all. When the bug happens, downloading is entirely dead. I have tried to figure what triggers this bug to occur, as it happens now and then on: * two home-made Asus A7N8X MB systems w/ Athlon XPs (1800 and 2400) running WinXP Pro and Mozilla 1.4 * a Compaq Presario notebook with 700 MHz Celeron running WinXP Pro and Mozilla 1.4 * an HP Vectra P-III 700 with XP Pro and Mozilla 1.4 ...but hasn't yet happened on the Dell Dimension 4600 w/ P4 2.4GHz w/ WinXP Pro with either Moz 1.4 or 1.5b. Then again, this Dell is only a couple of weeks old. In all cases, the delete/rename compreg.dat trick works for a while, sometimes for a very long time and sometimes just for a day. Unfortunately this is rather inconvenient, as it is no fun having to bookmark the open tabs, exit, kill quick-launch, delete file, re-open browser, reload tab group, wait for 8 or 9 tabs to all reload and hope that some of them didn't have navigation systems that don't reflect in the address bar, try the download again. I can't ever recall doing anything unusual between the last functional download and the first time the bug becomes noticeable. On one of the Athlon XP systems, the machine had only been built a few weeks before, and Mozilla had been installed for the first time just two days before. No custom theme is installed on any of these, though the Modern theme is in use on all. The following extensions are installed on all of these (including the Dell): OptiMoz Mouse Gestures, Googlebar, Flash Click-to-view, Tab Extensions.
I was using the classic theme and i still had the problem. I had none of those extensions installed either (i dont think i did anyway). Since i installed 1.5a the problem hasnt occured (yet)
The download manager window is not loadable when this bug is in effect for me. Clicking on valid download links or selecting the download manager in the menu does not load the manager. After renaming the corrupted file, download manager appears as expected.
When i was having the problem, if i clicked on a download it would bring up the "...source file could not be read." message, if i right clicked and hit "save *object* as..." download manager would simply fail to open, and i could not open it from the tools menu. So far it has not occured in 1.5a.
i'd say this is a priority one. Like those below, I get same message and I cannot download anything from anywhere, making this a LAME browser. Otherwise there is a lot to like if this can be fixed :) Curiously, IE does just fine. Is it a coincidence that I made Mozilla my default browser?
Strangely, my Mozilla is now downloading files again. I can't remember doing anything; just tried a download recently and it promptly performed the requested action.
I CAN REPRODUCE THIS! WAHOO! Okay, I have a 100% repro rate with: 1. View a PDF file in Mozilla (I'm running Acrobat Reader 6.0). 2. Close Mozilla. 3. Attempt to dowload anything. Notes: * It does not matter if the PDF loads completely (long download, close Mozilla window) or if it does. Both will allow this bug to happen. * The PDF can be local and the bug will still happen. * You have to close Mozilla for this bug to manifest. I've gone from a PDF to a different webpage using the same window and I'm able to download. Once I close Mozilla out, and open up a new instance (this includes Fast Launch coming back up after closing all Mozilla windows) this bug is manifest. * Deleting C:\Program Files\mozilla.org\Mozilla\components\compreg.dat (as comment #9 states) will make the symptoms go away. Please fix this!
The PDF interaction is interesting considering Bug #217796 is dealing with Adobe issues as well.
Well, I spoke too soon. Once again, I got the download message we have been talking about. By the way, I had not encountered a recent PDF document, either. Shucks.
1. View a PDF file in Mozilla (I'm running Acrobat Reader 6.0). 2. Close Mozilla. 3. Attempt to dowload anything. Is restarting Mozilla a step in this?
Well, I am back to downloading again. After the one failure I mentioned a couple of posts ago, I tried again (on a different site) and the download manager came up and my file downloaded OK. Must be a computer thing.
> 2. Close Mozilla. > 3. Attempt to dowload anything. > Is restarting Mozilla a step in this? Yeah, by "Close Mozilla" I mean completely close all windows related to Mozilla, and I assumed "Attempt to download anything" would implicitly mean re-openning Mozilla. I haven't tried this on any other machines to make sure it's not somehow related to just my configuration, and I also haven't attempted different PDF files to make sure you don't need a specific PDF.
*** Bug 219822 has been marked as a duplicate of this bug. ***
I'm getting this with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030917 Firebird/0.6.1+ Is this the right bug to monitor for this?
Sorry but forgoth to mention a possible workaround if you copy the <filename> file give the name of the file your trying to download and try downloading again overwriting the renamed <filename> file will usually make it be resumed so if it's a big one you don't need to start over. But it doesn't always work...
Since we are moving mozilla to be a end user application...IE no more Netscape It makes sense for us to dig in and try to triage this bug before 1.5, if we release 1.5 as a end user release and this bug creeps up, we could really get pie in the face. IMHO of course...
...which is exactly why I'm puzzled over the removal of the "Blocking" flag. The bug seems to be rather common from reading the above commentaries and noticing the large number of duplicate reports, and 4 of my 5 machines have experienced it. My wife doesn't even want to use Mozilla since I now have to delete "compreg.dat" for her every other day before she can successfully download endless "Sims" objects. If fixing a fairly common bug that breaks a critical function such as downloading isn't deemed necessary, then so be it. But it does make the product look rather stupid to the public or at least to the fence-sitting evaluator.
Exactly, for Mozilla to ever succeed it needs to be twice has good has IE and work perfectly 99% of the time, or else people will just move back to IE (that just works) and everybody would lose with that. I myself remember the countless times i consider changing back because of bugs like this.
OK. Does anybody who sees this bug have a nightly from today? If so, please create a helperappservice log, like this: Exit mozilla, enter this in a command prompt: set NSPR_LOG_MODULES=HelperAppService:2 set NSPR_LOG_FILE=c:\dlerror.log start mozilla.exe Then reproduce the error. After that, please add a comment with the content of c:\dlerror.log. thank you.
16 years ago
Attachment #132174 - Attachment mime type: application/octet-stream → text/plain
Peep Chaintreuil: can you try the steps mentioned in comment 51?
regxpcom cannot register the component uriloader as it bombs out doing so. I guess the mozilla internal process to create compreg.dat cannot do this as well, hence the missing lines in compreg.dat. Hence the missing user-interface for this module. regxpcom core dumps after opening liburiloader.so (unix) and bombs out (SIGSEGV) in nsGenericModule::RegisterSelf. I assume this is because of either liburiloader misbehaving (not conforming to API), or liburiloader to do something which is new or too hard for XPCOM to handle. on my build this bug is easy to reproduce, it's worse: it won't go away! has anyone informed the uriloader people? does it make sense to start debugging regxpcom?
Where did liburiloader.so come from? This library is no longer built; the uriloader is linked into libdocshell.so nowadays. Are all the people seeing this using installer builds? Is the problem that installer is not cleaning out the old and bogus liburiloader.so? > has anyone informed the uriloader people? You just did. ;)
> hence the missing lines in compreg.dat. which lines _are_ missing? I didn't spot any that were... this bug _totally_ lacks required information to fix it.
It seems true that regxpcom cannot handle incompatible components of previous releases. it should ignore these, but it doesn't and may core dump. This is not causing this bug (203689) however! I'll try to solve it and log it in the appropriate place. Without old components in the way, 203689 still occurs. It still looks like a compreg.dat or xptr.dat problem. The missing lines are mentioned in comment#8 in Bug 180672 and indicate that the documentloader wasn't able to register itself.
Downloading: http://members.xoom.virgilio.it/algoritmi/Visualwx_0-77.exe dlerror.log [content] 0: Error: readError, listener=0x37fecac, rv=0x804B0014 Hope that helps.
that corresponds to this error... 186 /** 187 * The connection was established, but no data was ever received. 188 */ 189 #define NS_ERROR_NET_RESET \ 190 NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_NETWORK, 20) (i.e. "Connection reset by peer"?)
*** Bug 208275 has been marked as a duplicate of this bug. ***
Internet Explorer did show "Connection reset by peer" but i still expeted mozilla firebird to handle this better then ie.
How do we better handle the website suddenly dropping the connection, exactly?
I'm just a clueless user here but couldn't mozilla just reconnect to the website and resume it's work? or at least leaving an option to resume it it's a pain to start a download over when you were at 96% even more if you have **** traffic limits... and why not a better error message dialog with a nice link to mozilla help center (*hint*) explaining why it may be happening and how to solve it.
both issues are a different bug
I agree, the "Connection reset by peer" bug, which isnt actually a bug at all, is a seperate issue. Do all the people still experiencing this bug have a recent version? i experienced it under various versions of 1.4, but i installed 1.5a some time ago and have not experienced it since then.
Since migrating to Firebird 0.7RC2 and Moz 1.5RC2 I have not seen this issue either, it seems to only affect 1.4....which since its fixed in 1.5 and NS is no longer a priority, I think the fix should be upgrade to 1.5
I have not seen the problem since upgrading to Mozilla 1.5 RC2. I am sure that if the bug was still there, I would had seen it by now. Has anyone else seen it with Moz 1.5b or later?
that's three votes for WORKSFORME... please reopen this bug if it can be demonstrated with a recent trunk build.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Happens on Netscape 7.1 on all my win2k machines too.
Netscape 7.1 is ancient. Please don't even bother reporting bugs on it unless they're a problem in a current (1.6) mozilla build.
*** Bug 202862 has been marked as a duplicate of this bug. ***
*** Bug 217451 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** This bug has been marked as a duplicate of 180672 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 15 years ago
No longer depends on: 180672
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.