Closed Bug 203689 Opened 21 years ago Closed 20 years ago

Unable to download files ("...could not be saved, because the source file could not be read.")

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 180672

People

(Reporter: mcsmurf, Assigned: dougt)

References

Details

(Whiteboard: WORKAROUND: possible workround see comment #24 or comment #9)

Attachments

(4 files)

Corrupt(?) compreg.dat
140.76 KB, text/plain
Details
compreg.dat that just corrupted
155.17 KB, text/plain
Details
Newly created, working compreg.dat
146.46 KB, text/plain
Details
dat.com
155.68 KB, application/octet-stream
Details 
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
OS: Windows 2000 → Windows XP
Attached file Corrupt(?) compreg.dat — 

    
  

        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.
Flags: blocking1.4?

    
    

    
  
*** 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. ***

    
  
Flags: blocking1.4?

    
    

    
  
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
Depends on: 180672

    
    

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

    
    

    
  
*** Bug 216595 has been marked as a duplicate of this bug. ***
Flags: blocking1.5?

    
    

    
  
*** 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.

    
  
Flags: blocking1.5? → blocking1.5+

    
    

    
  
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...

    
  
Flags: blocking1.5+ → blocking1.5-

    
    

    
  
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.

        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[334570]: 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
Closed: 21 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. ***

    
    

    
  

      
      
      
      

        Attached file
          
        dat.com
        — 
      

    


  

    
    

    
  
*** 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
Closed: 21 years ago → 20 years ago
No longer depends on: 180672
Resolution: --- → DUPLICATE

    
  
Component: XPCOM Registry → XPCOM
QA Contact: doug.turner → xpcom

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: