Closed Bug 123662 Opened 18 years ago Closed 16 years ago

"File / cannot be found. Please check the location and try again" when loading page

Categories

(Core :: Networking: Cache, defect, major)

defect
Not set
major

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: robert, Assigned: nallen)

References

Details

(Keywords: verified1.7)

Attachments

(14 files)

114.41 KB, image/jpeg
Details
251.15 KB, text/plain
Details
70.08 KB, image/jpeg
Details
209.67 KB, application/octet-stream
Details
2.62 KB, text/plain
Details
40.42 KB, image/png
Details
184.14 KB, application/octet-stream
Details
8.82 KB, text/plain
Details
2.92 KB, text/plain
Details
41.23 KB, application/zip
Details
6.78 KB, application/zip
Details
67.77 KB, application/zip
Details
882 bytes, patch
darin.moz
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
254 bytes, text/plain
Details
Build 2002020406

- Open a browser window
- Type "bugzilla.mozilla.org" into the location field
- Hit return

* The page fails to load, showing an alert that says "The file / cannot be
found.  Please check the location and try again", even though the URL works fine
in IE (see attached screenshot).

Note that I've seen this with other URLs (my.yahoo.com, for example), but the
bugzilla one is the most consistent source.
I've seen this as well in 0.9.8 (same build as reporter).  It only happens
sometimes.  I just try appending something like index.html to the URL, and then
things go fine (and the problem doesn't seem to happen from that point on).

Someone please confirm.
-> Networking:http
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
QA Contact: doronr → tever
verify the following:

1) that only one instance of mozilla is running
2) try running mozilla w/ a fresh profile

let me know if either of these solve the problem.
- After quitting Mozilla (and confirming the process is gone in Task Manager), I
restarted.  The problem still exists.

- I created a 2nd profile, "Guest", and launched using that.  The problem does
*not* exist in the new profile.  If I quit and log back in under my usual
profile, I see the problem again.  I repeated this several times and the
behavior is consistent.  Everything works w/ the new profile, but is broken with
my usual profile.
you might try clearing your disk cache under Preferences->Advanced->Cache and
see if that doesn't help with the Guest profile.

another thing you can do that might help us understand the problem would be to
set the following environment variables:

  set NSPR_LOG_MODULES=nsHttp:5
  set NSPR_LOG_FILE=http.log

and then run mozilla from a DOS box, and upload the file http.log to this bug.

then we might have some chance of understanding what is wrong with your other
profile.  thx!
My existing profile is the only copy i have of my mail, yet i can't find an
export option in mailnews so i can bring my mail into a new profile.  Am i
missing something?
Okay, just did the following:

- Tried hitting bugzilla.mozilla.org again this morning before I changed anything.
* Still seeing the bug
- Cleared both the disk and memory caches
- Tried again
* No longer seeing the bug - everything is working fine now.

So, it looks like this was an issue with the cache(???)  Unfortunately I didn't
get a chance to set the env vars as you suggested before the problem went away
so I don't have any logs to upload.  However, I suspect this will reappear at
some point so I'll set them now and wait to see what happens.  (Hmm... does
generating log files impact performance/disk usage?)

Also, do I need to run mozilla from the console for the log files to get
generated?  You don't seem to have specified any command line flags I need to
use ... wouldn't launching from the quick-start icon produce the same results
once the env vars are set?
robert: running with the environment variables set will cause the log files to
grow.  and they will grow very quickly, and get very large.  this does have a
significant impact on performance and will chew up lots of disk space.  i'd
suggest that you run the browser as usual, and if the problem shows up again,
then shutdown the browser and try running it from the command line after setting
the environment variables.  in other words, don't bother setting the environment
variables until after you can reproduce the bug.

and, if you set the environment variables in a DOS box, then they will only
effect applications launched from the DOS box.  you can set environment
variables in the control panel that effect all applications run on your
system... including mozilla when run via the quick launch icon.
cc'ing gordon... another example of a "file not found" bug... this one was only
resolved after the user cleared their disk cache.
*** Bug 124729 has been marked as a duplicate of this bug. ***
*** Bug 120625 has been marked as a duplicate of this bug. ***
I experienced this (with the same dialog contents) on Linux (please set OS to
ALL) with 0.9.8 (build 2002020415) and nightly build 2002030108 was running from
with the same profile at the same time. The message appeared in the 0.9.8
windows (tried in new and older ones), but the address worked in the nightly build. 
I didn't clear any cache manually (I have a squid proxy set up, and have 
"When the page is out of date" set in the prefs), but after closing every
Mozilla window, and starting both version again, the page (bugzilla.mozilla.org)
loads w/o errors.
bugs: it is invalid to run two instances of mozilla w/ the same profile.  that
is unsupported and may even cause corruption in your profile.  DO NOT RUN TWO
INSTANCES OF MOZILLA WITH THE SAME PROFILE AT THE SAME TIME!!  you're only going
to regret it ;-)
mass futuring of untargeted bugs
Target Milestone: --- → Future
got this today (Mac OS 9.1, Build 2002100911)
with this url: http://bugzilla.mozilla.org/show_bug.cgi?id=174197

This link was in a mail sent by bugzilla

I launched the page manually using only the browser. After that the Link in the
mail works

may be a cache problem. In this case a more explicit message will be usefull.
This bug has been occuring a lot lately on my version (1.1 on Windows ME). 
Clearing the cache seems to fix it, as others have mentioned. It seems to 
happen to me when I have a lot of stuff open on the desktop and several tabs 
open in Mozilla.

Mozilla 1.1: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826
mike: the latest pre-release version of mozilla 1.2 (the latest mozilla nightly
build) may fix the problem you are seeing.  since mozilla 1.1, we've fixed some
bugs that could trigger this problem.
*** Bug 179208 has been marked as a duplicate of this bug. ***
*** Bug 183008 has been marked as a duplicate of this bug. ***
*** Bug 183437 has been marked as a duplicate of this bug. ***
*** Bug 183476 has been marked as a duplicate of this bug. ***
*** Bug 180655 has been marked as a duplicate of this bug. ***
Summary: "File cannot be found" when loading page → "File / cannot be found. Please check the location and try again" when loading page
*** Bug 155973 has been marked as a duplicate of this bug. ***
bug 155973 was originally merely about the error message, but it got rather
confused with this issue, and I couldn't see the value of two bugs.  the error
message should be better, whatever the cause.
I still see this bug when accessing sciencedaily.com, appending index.htm to the
url allows me to access the site.  I am using .... 

Mozilla 1.3a
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021204

This should mean that it still occurs despite comment #19
*** Bug 183968 has been marked as a duplicate of this bug. ***
I can confirm that this bus still exists. In the latest release 1.2.1.  

The only time I seem to get the bug is when there are dynamic pages that contain
continually updated information. i.e. http://news.google.com/ 

To duplicate go to a page that the information is updated frequently go into an
article/another page in that same domain. Wait for the previous page to be
updated then hit the “go back one page” button. This is the catalysts for the
error. It appears that Mozilla is checking for the page, knows it has been
updated but instead of grabbing the new page off the site, it tries to take it
out of the cache which has just been invalidated. 

The error should happen most frequently with the steps outlined above. But I
need someone to confirm.
I can confirm.  This just happened to me using news.google.com with Mozilla 1.2.1
The bug there's also in Phoenix 0.5!
I have seen this bug only when i try to open http://windows.zdnet.it
I experienced this with 1.3a at www.dilbert.com. Whenever I got the message, 
Mozilla would crash in Necko.dll upon quitting. Cleaning the cache helped, so I 
can no longer find the exact crash info.
I got this bug on Windows NT 4.0 with Mozilla 1.31a trying to access
www.redhat.com.  It happened a few other times on other sites, but this one
happened every time.  I cleared memory and disk cache and the problem still
persisted.  But even after clearing the disk cache, my cache folder had 45MB of
stuff.  So I deleted all of this and the bug went away.
*** Bug 187710 has been marked as a duplicate of this bug. ***
2003011508w32. http://news.google.com, i clicked on an article and then pressed
the back button. now i can't load news.google.com. If the file can't be found
then we need to offer to hit the network.
*** Bug 192443 has been marked as a duplicate of this bug. ***
*** Bug 141847 has been marked as a duplicate of this bug. ***
platform/os->all per latest duplicate
OS: Windows 2000 → All
Hardware: PC → All
Mozilla 1.2.1, Linux 2.4.20-20, squid-2.5.STABLE3
Now seeing this with Firebird 0.7+ builds on Win32:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031202
Firebird/0.7+ (O1 G7 SSE optimized)

fark.com is one example of where I see this.  Clearing the disk cache fixes the
problem.
I had this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031212 Firebird/0.7+ and earlier. Clearing cache removed the alert.
For me it often occurs when I hit Back button at dynamically-generated pages
such as web forum to flip pages back. It shows alert even though it should
clearly be in cache.
FYI I get this often with URL other than /, for example places like pages in
Mozillazine forum or Slashdot, with something like "The URL
"http://forums.mozillazine.org/viewtopic.php?t=251617dd9f6b3e7b64" is not
found." instead of root not found, as if pragma no-cache really means no cache
in anywhere.

My current build is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031216 Firebird/0.7+
this is my first try using a bug report - sorry if not enough info presented.  I
am getting the file not found error with a URL that works fine in other
browsers.   From reading the other comments it seams to span all OS. I have OS X
on two macs.  The funny thing is that the problem only occurs on one of them. 
Same build on another machine works fine.  
*** Bug 229685 has been marked as a duplicate of this bug. ***
*** Bug 168061 has been marked as a duplicate of this bug. ***
This bug seems to trigger much more frequently for me in 1.6 than before.  I
only get it when going to another website and then hitting the back button; for
example, if I go to www.arstechnica.com (lately the bug has happened most
frequently there), then to another site, and then hit back, I get the error (and
keep getting it each time I hit back); but if I retype "www.arstechnica.com"
things work fine.
(In reply to comment #47)
> This bug seems to trigger much more frequently for me in 1.6 than before.  I
> only get it when going to another website and then hitting the back button; for
> example, if I go to www.arstechnica.com (lately the bug has happened most
> frequently there), then to another site, and then hit back, I get the error (and
> keep getting it each time I hit back); but if I retype "www.arstechnica.com"
> things work fine.

I'm fairly sure I'm seeing it more often, in more places, with more
randomization, with the 0.8+ nightly Firebird builds as compared to 0.6 and 0.7.
 Symtoms are identical.
Re: Comment #47

> This bug seems to trigger much more frequently for me in 1.6 than before.

Yes, with Mozilla 1.6 this bug happens to me really often, and not with 1.2 to
1.5. With the same computer, etc. (Windows 98). In fact, in my case 1.6 is the
first version that gives me this problem (with the alert when clicking on some
-before working- links, also with back button to previously visited pages...).

Like others, I needed to start again Mozilla or to use IE to visit some pages,
but today I've just tried clearing cache as suggested here, and indeed it seems
to fix the problem, at least for now.
*** Bug 232524 has been marked as a duplicate of this bug. ***
*** Bug 231339 has been marked as a duplicate of this bug. ***
*** Bug 232606 has been marked as a duplicate of this bug. ***
See also later comments in bug 172305 which seems to have also morphed (like
this bug) into covering this new or newly exposed problem. 
An HTTP log of this or similar failure can be found in one of the dupe bugs. See
attachment 98783 [details] and bug 168061 comment #3.
*** Bug 233156 has been marked as a duplicate of this bug. ***
*** Bug 176232 has been marked as a duplicate of this bug. ***
You don't have to clear the cache to get rid of the behavior.   It works on my
machine (Moz 1.6, Win XP) if you go to Edit -> Preferences -> Advanced -> Cache
and change the "Compare the page in cache to the one on the network" to "Every
time I view this page"

I had the problem with www.fark.com using the back button from reading comments.
 I generated the error, changed the pref, and the problem went away. 
(In reply to comment #57)
> You don't have to clear the cache to get rid of the behavior.   It works on my
> machine (Moz 1.6, Win XP) if you go to Edit -> Preferences -> Advanced -> Cache
> and change the "Compare the page in cache to the one on the network" to "Every
> time I view this page"
> 
> I had the problem with www.fark.com using the back button from reading comments.
>  I generated the error, changed the pref, and the problem went away. 

How can I do this in FireFox?  I get this exact same problem on Fark a few
times/day.
Question: At what point does a "good citizen" (someone who filed a bug in an
effort to improve this product) have the right to get a little annoyed at the
email he gets about the bug's [seemingly endless] updates?

I'm a reasonable guy and all, but I've been getting updates on this thing for
OVER TWO YEARS NOW.  I mean, come on!  It's been fun but, frankly, I really just
don't care anymore (although I might if I'd actually seen this bug happen in the
last 18 months... but I haven't).  :-)

Anyhow, I don't suppose there's a way to turn off my email notifications for
this bug only, or assign someone else as the original reporter, or have someone
else create a new bug and close this one?

Sorry, just a little micro-rant this morning.  Have a nice day.
I hate to spam this bug (especially after comment #59), but this bug has been
referenced quite a bit from the MozillaZine Firefox forums and other locations
because this error ("The file / cannot be found") is occurring a lot when users
click the Back button and when they attempt to View Source for a page (I
personally have seen a lot of both situations).

However, I've been using Mozilla for many years, and Firebird since 0.6, and
I've never seen these issues until upgrading to Firefox 0.8.

My point is that this bug is very old, and the errors in Firefox have just
appeared, so I am suggesting that perhaps we are seeing a new issue.  Either
that or something happened in Firefox 0.8 that really brought this bug to light.
(In reply to comment #59)
> Anyhow, I don't suppose there's a way to turn off my email notifications for
> this bug only, or assign someone else as the original reporter, or have someone
> else create a new bug and close this one?

http://bugzilla.mozilla.org/userprefs.cgi?tab=email
So is can a(In reply to comment #58)
> (In reply to comment #57)
> > You don't have to clear the cache to get rid of the behavior.   It works on my
> > machine (Moz 1.6, Win XP) if you go to Edit -> Preferences -> Advanced -> Cache
> > and change the "Compare the page in cache to the one on the network" to "Every
> > time I view this page"
> > 
> > I had the problem with www.fark.com using the back button from reading comments.
> >  I generated the error, changed the pref, and the problem went away. 
> 
> How can I do this in FireFox?  I get this exact same problem on Fark a few
> times/day.

So can anyone answer my question?
(In reply to comment #58)
> (In reply to comment #57)
> > You don't have to clear the cache to get rid of the behavior.   It works on my
> > machine (Moz 1.6, Win XP) if you go to Edit -> Preferences -> Advanced -> Cache
> > and change the "Compare the page in cache to the one on the network" to "Every
> > time I view this page"
> > 
> > I had the problem with www.fark.com using the back button from reading comments.
> >  I generated the error, changed the pref, and the problem went away. 
> 
> How can I do this in FireFox?  I get this exact same problem on Fark a few
> times/day.

Looks like "about:config", change browser.cache.check_doc_frequency to 1.  (At
least, that's what mozilla does when you change this configuration item.  I
don't think that firefox would have changed this behavior.)
If it helps, I have never experienced this bug on any Firebird/Firefox build,
starting all the way back with 0.6.1. My current build is Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.7a) Gecko/20040221 Firefox/0.8.0+ (daihard: XFT+GTK2;
opt. for P4/SSE-2), and it has never displayed any of the many error messages
referenced in this bug.
I've had it happen sporadically over the years, but can't really pin it down.
In the meantime until this bug is fixed, a more complete alert including the
workaround would be surely helpful to many users. I think the current alert is:

fileNotFound=The file %S cannot be found. Please check the location and try again.

See for instance the SeaMonkey English source at:
http://lxr.mozilla.org/seamonkey/source/docshell/resources/locale/en-US/appstrings.properties#21

IMHO, a helpful alert to cover also this bug (a frequent bug lately) would be
anything like the following, in the English version:

fileNotFound=The file %S cannot be found. Please check the location and try
again. If the location is correct, please try clearing cache.

I would submit this simple line as a proposal for a temporary patch, but I'm not
familiar with the Mozilla hacking process. Therefore, it's just a suggestion for
others who probably may do something like this easily. And translations of this
or any similar line would be a one-minute task for the Mozilla translation
projects. ;-)
Or, better yet, don't even show a dialog and just clear the cache (for that site
only?) automatically and try fetching the page again.  Only show the dialog if
it fails the second time.

A hack?  Oh definitely.  But a hack that works is better than nothing at all
(... or is it?)
Assignee: darin → asa
QA Contact: tever → asa
(Continuing my rant from comment #59)

A summary of two years of activity on this bug:
a) It has 33 votes, 40+ Cc'ers, 20 duplicates (i.e. lots of interest in seeing
it fixed)
b) There's not a single comment that attempts to explain why the cache is
causing this problem, let alone any actual attempts to fix it.
c) The assignee (darin@meer.net) hasn't looked at this bug in quite some time
(since 11/02?)
d) ... and he has ~550+ bugs on his plate.

Which puts me in the rather odd position of concluding that regardless of how
much this bug *should* be fixed, it probably never will be fixed.

In a last ditch effort to see something happen with this, I'm assigning this to
Asa to see if maybe *he* has some ideas on how to get progress made.  I'm not
sure how appropriate this is but screw it, it can't get any worse.

Furthermore, consider this a countdown warning.  Unless I see _real_ progress
made on this bug, I'll be closing it on or sometime after May 1, 2004.  And then
one of you <strike>suckers</strike> generous folks on the Cc: list can open a
new bug with _you_ as the reporter.

Have another nice day!
-> back to Darin

rkieffer@pacbell.net: I removed your bugzilla permissions for this. (suckers..)
Assignee: asa → darin
QA Contact: asa → httpqa
Like to add my name to the pot as well, i get it when i go to www.fark.com, this
happened in previous firefox builds (AKA firebird). All other pages work fine.
Only running one instance of firefox.
If people actually want this bug fixed, they should probably try following the (very detailed) instructions given by Darin for creating an http log. This will mean that there is some actual information to go on when trying to track down the source of the problem in code. Without that information finding the buggy code will be impossible, and so a fix won't be forthcoming regardless of the length of time that the bug's been open. In general, whining about a problem doesn't get it fixed, but producing information (logs / testcases / etc.) that actually helps to solve the problem does.
Personally, I've never experienced this bug (I'm running Linux - the bug seems to be Windows only), so I can't offer any more help.
This is a log file of a single http connection exhibiting this bug;
unfortunately, it does not contain the original request (to fark.com, which
seems to be a common offender) which was supposed to have stored this document
in the cache in the first place.  Hopefully someone else can make some sense
out of this.
Just a quick pict of a bug I feel that's related to this. On occation while
browsing the forums using the 'back' on my mouse I get this error. It's
happened alot, but never reproducible. Clearing cache allows me to hit back,
using the same methods done previously.
Here's a http log of the error. 

Aprox line 539 is where the error shows up. I hit back three times and no go.
Came to this site to submit the log. Hit back again (on the forums) and still
error. Cleared my cache and then was able to hit back successfully.

Everything is within the logs. Might be more than you need, but my assuption is
more debugging the better.

This log can corralate with my previous png attachment. While it was not done
at the same time, it's the same error.
I've (kind of) been able to reproduce it at Mozillazine:

1. Go to the MozillaZine forums (I usually use this link in my bookmark toolbar:
http://forums.mozillazine.org/index.php?c=4)

2. Click any one of the forums
3. Open a new tab or window and repeat steps 1,2

When I try to go back to the first page
(http://forums.mozillazine.org/index.php?c=4)
from either tab, I get the error message.

I've done it using the OS X and Windows versions.

But I asked a couple of friends to try it and they had no error.  Could it have
something to do with me using that bookmark?  I tried the same steps by going
through the mozillazine front page and did not get the error.

The only extension I am using is AdBlock.
(In reply to comment #73)
> Just a quick pict of a bug I feel that's related to this.

That's bug 172305.
(In reply to comment #76)
> (In reply to comment #73)
> > Just a quick pict of a bug I feel that's related to this.
> 
> That's bug 172305.

Sorry about that. I'll add my data over to their bug. I felt they were related.


On a real related note, The file / cannot be found - Log of trying to goto
Fark.com.
Error happened when attempting to goto a bookmark of mine. I shutdown Firefox
and attempted to goto the site again. No luck. I shut down firefox, ran the
debug on a new instance of Fx only attempting to hit Fark 2 times then shut
down.

Log file doesn't contain any successful hits on Fark.com
This happened while surfing Mozillazine.  It seemed to happen when you have a
lot of gibberish like this on the end of the url address:
 
http://forums.mozillazine.org/viewtopic.php?t=61163&sid=ed0965976a102fd8fd57c056a88e1fe8

I had also had a bunch of pages in my cache to cycle back to.  I cycled back far
enough while hitting a long URL with gibberish on it and "Wham!" file not found.
 It might be the gibberish or the having a bunch of pages to cycle back to.  I
am trying to reproduce.   
Oops!  Sorry for the spam.  But notice the "=" sign in the URL's listed and
"php" and also the gibberish stuff like "4be5gjk38s".   These types of URL's
produce the error.   
I get this bug when going to Fark.com, but only when I click a link before the
page has finished loading fully... does that possibly corrupt the cache?
Does a very long URL overflow the storage allocated to the URL, and does the
program then reset the contents of the URL buffer to "/"?
(In reply to comment #80)
> only when I click a link before the page has finished loading fully... does
that possibly corrupt the cache?

Interesting observation... I thought about some of the URLs for which this has
been a problem for me, and looked at some of the reported links in the dupes,
and it seems like the pages frequently seem to use javascript links, javascript
rollovers, and/or targeted links.  This is speculation, but could calling
javascript and then leaving a page before it's finished loading leave the cache
entry in an inconsistent state?

I don't really know where to begin looking to check on that, but hopefully it's
a helpful idea.
An Email from a random admirer:

    Date: Sat, 20 Mar 2004 13:26:06 -0600
    From: Midnight Rambler <jszyman2@merr.com>
    To: rkieffer@pacbell.net
    Subject: Bugzilla Bug 123662

    Just installed mozilla 1.7 and noticed Bugzilla Bug 123662 "File / 
    cannot be found. Please check the location and try again" occurs in the 
    browser as others have reported.  Bug not a problem in v 1.6.

    Not sure how to add my input at 
    http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser.
    
    Sorry to bother you.
*** Bug 239000 has been marked as a duplicate of this bug. ***
*** Bug 238666 has been marked as a duplicate of this bug. ***
*** Bug 237141 has been marked as a duplicate of this bug. ***
I've got a website with a login screen, after login some cookies are set, and
the user clicks on the link to return to the homepage.  If the user clicks a
link from the homepage, then uses the back button to go back to the homepage
they get the aforementioned "file / not found".  This seems to differ from the
other explinations I've read, as there is no long url, and it ONLY happens
directly after logging in (if you click on home again, then another link, then
use "back" to go home, it's fine)  Only the first view of the front page after
logging in.  I was thinking this might help diagnose, as the homepage is php and
renders differently if you are or are not logged in, which would lend some
credibility to why clearing the cache fixes the problem, which it does.

Regards,
Jason  
Can anyone show how long it takes for this to happen?  Usually I don't find my
cache corrupted until after I have surfed the web for 30 minutes.  BTW: This
might not be just a php bug.  I had hit Drudge Report then hit a "jsp" page
linked off of it then went back to home.  The same error occured.  Drudge didn't
put any cookies on my PC. Mostly I have cookies disabled. Of course a nasty java
script advertising box came up on the home page before it all happened.   
*** Bug 239413 has been marked as a duplicate of this bug. ***
I managed to hit this in a debug build.  When visiting a page I got:

WARNING: cacheMap->DeleteStorage() failed., file c:/project/mozilla/mozilla/netw
erk/cache/src/nsDiskCacheStreams.cpp, line 491
###!!! ASSERTION: Flush() failed: 'NS_SUCCEEDED(rv)', file c:/project/mozilla/mo
zilla/netwerk/cache/src/nsDiskCacheStreams.cpp, line 447
###!!! ASSERTION: file descriptor not closed: '!mFD', file c:/project/mozilla/mo
zilla/netwerk/cache/src/nsDiskCacheStreams.cpp, line 330
###!!! ASSERTION: deleting dirty buffer: 'mBufDirty == PR_FALSE', file c:/projec
t/mozilla/mozilla/netwerk/cache/src/nsDiskCacheStreams.cpp, line 734

The site loaded that time but future accesses get the "File / cannot be found"
message.  I'm going to try to poke around with this a bit in the debugger.
timeless has hit this before bug 187034 and bug 187035

I wasn't able to dig much out of the postmortem.  This is fustrating to go
through as most of the evidence is gone by the time you see something is wrong.
 Normal browsing resumed as soon as the cache entry expired.
Component: Networking: HTTP → Networking: Cache
I'm using: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6) Gecko/20040206
Firefox/0.8, and I have experienced this same bug.

When it just happened I had been composing an email message and my LEAF/Bering
firewall timed out for inactivity and dropped the link.  Of course trying to
send the message prompted Bering to restart the link, but Firefox timed out
while that happened.  When I clicked on Send again, the link was up and the
email was sent.   Then I clicked on the down triangle next to the Back icon,
selected the original  page I came from at the bottom of the list and got this
error message.

It leads me to suspect possibly the Firefox timeout has something to do with it.
*** Bug 240018 has been marked as a duplicate of this bug. ***
Using Firefox .8; from about:blank to fark.com.  This bug is extremely
annoying.  What more can we do to provide useful information to track it down?
Attached file http failure log
Posted for y3k on mozillazine: this log "navigates to a page with a flash game
on after losing you're redirected to a highscore page which has the infamous
/score.php cannot be found." It's 9000 lines long and contains lots of
suspicious-looking cache accesses.
Attached file http error log
Posted for y3k on mozillazine: this second log "goes directly to the page
containing the game via the history menu after losing the error occurs."
When accessing http://www.books.ch, i got just pages and pages of source code,
but no site displayed. When I reload, I get the well known error message. I
already had Preferences->Advanced->Cache->Compare the page... = Every time I
view the page, so I tried to put the Cache size on 0MB, restarted Mozilla and
tried again. I got pages of source code again, reload, and then parts of the
page are displayed correctly, the table cell on the right still as source code.
I can only access the page if I turn off Preferences->Debug->Networking->Enable
Disk Cache.
I see this bug most often at the main page at slashdot.org, www.scripting.com, 
and somewhat less often at the various discussion forums at keenspot.com, for 
example http://forums.keenspot.com/viewforum.php?f=5

I have a hypothesis that it happens when I read the main page, click a link to 
go elsewhere, then the main page has changed, and then I click the back 
button. These are all sites where the page changes with some frequency.

But it doesn't happen every time the page has changed before I hit the back 
button.

Now that I see the instructions about the log file, I'll try to get one and 
attach it here.
I recently viewed a site that where the JPG picture link was broken.  I decided
to try the technique I use for this bug, clear the cache.  It worked!  The image
now loads fine.  So I speculate that this bug is also effecting images.  Fix
this bug and there will be much fewer broken images. 
*** Bug 240953 has been marked as a duplicate of this bug. ***
Is it impossible to introduce some temporary patch that simply tries to download
again from a URL quietly instead of showing this dialog? I've seen this alert
dialog nowhere other than where this cache failure occurs.
*** Bug 241862 has been marked as a duplicate of this bug. ***
*** Bug 237641 has been marked as a duplicate of this bug. ***
I'm using the MozJF 20040417 build under Windows XP. I had the connections
setting to use a SOCKS 4 proxy server running on localhost (it was done with
the -D option to ssh). I'm sure I have seen this many times while not using a
proxy server.

I was browsing for a while, then went to http://slashdot.org/ by scrolling down
the history in the address bar and clicking on the URL. I did some more
browsing and clicked on back button to go back to http://slashdot.org/ from
another page on slahdot. That's what I got the error. After clicking on the OK
button of the error dialog I saved http.log.

I then clicked on the back button again, got the error again, and saved
http.log again.

I edited the log to delete everything from the beginning to a little before the
first mention of slashdot.org. I inserted the following text between the end of
the first log and the new text that was added by generating the error a second
time:

*******************************************************
The above was saved after the error appeared.
The rest of this is what was added to the log when I
clicked the back button again, got the error again, and
clicked OK on the error dialog
********************************************************
Keywords: helpwanted
I see this bug consistently on my blog (very very often):

http://aebrahim.blogspot.com/

I really don't mean this as a plug for my blog, but I think having a testcase
where this problem is easily reproducible would be helpful.

I'm using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a)
Gecko/20040429 Firefox/0.8.0+.
Flags: blocking1.7?
Comment 97 sounds like bug 241085 (garbage on first load fixed by reloading),
but that may simply be a duplicate of this one.

Bug 180831 (the page loads completely blank) seems suspiciously related.

Considering comment 105 on this bug, the common thread between this bug and
those two is blogspot.com.
Following up on my previous comment, this fixes the problem for me.
Assignee: darin → nallen
Status: NEW → ASSIGNED
Attachment #147430 - Flags: review?(darin)
Comment on attachment 147430 [details] [diff] [review]
Doom records with corrupt storage

I've asked Gordon Sheridan (the author of this code) to review this.
Comment on attachment 147430 [details] [diff] [review]
Doom records with corrupt storage

r=gordon, sr=darin

comments from gordon via private email:

> Hi Darin,
> 
> I think the patch is okay.  It would be interesting to know which case
> in nsDiskCacheMap::DeleteStorage() is failing (separate file or cache
> data block file).  If we fail deleting blocks from the block file, it
> might be a good idea to throw the disk cache out and start a new one.
> If the deleting a file fails, then why?  If it's because the file
> wasn't found, then simply dooming the record should be sufficient (or
> course there are a number of reasons why we file could be missing...).
> If we can't delete the file for some other reason, then we should try
> moving it aside, and if that fails as well, something is really weird.
> 
> Without knowing more, the patch doesn't appear harmful, and may
> "properly" fix the particular error case (as seems to be reported).
> Ah, if we had loads of time it would be good to investigate this and
> definitively fix it (and related error cases).  If this patch fixes
> the immediate complaints, the problem probably doesn't merit such an
> investment of resources.
> 
> I'll give it *my* thumbs up.
> 
> -Gordon
Attachment #147430 - Flags: superreview+
Attachment #147430 - Flags: review?(darin)
Attachment #147430 - Flags: review+
fixed-on-trunk

though as gordon's email suggests, there may still be other cases to consider,
i'm going to mark this bug fixed.  we should address any other related issues in
a separate bug.

thanks nallen!
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 147430 [details] [diff] [review]
Doom records with corrupt storage

This looks like a safe fix for the 1.7 branch.
Attachment #147430 - Flags: approval1.7?
Keywords: helpwanted
Comment on attachment 147430 [details] [diff] [review]
Doom records with corrupt storage

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #147430 - Flags: approval1.7? → approval1.7+
(In reply to comment #110)
> (...) there may still be other cases to consider (...)

Well, just in case, something interesting is that this cache bug -hopefully
fixed already (thanks!)- seemed to happen with web pages that don't require
cache, such as dynamic pages and also static html pages with no-cache http headers.

For example, an .htaccess file affecting pages that suffered this bug:

<FilesMatch "\.html$">
Header append Expires 0
Header append Cache-Control max-age=0
</FilesMatch>

And yes, the bug (a "cache" bug for "no-cache" pages, curiously enough)
disappeared always for a few days by clearing cache.

Thanks again for the patch.
fixed1.7
Flags: blocking1.7?
Keywords: fixed1.7
*** Bug 243088 has been marked as a duplicate of this bug. ***
After the patch, testing this bug during a few days with the new Mozilla 1.7
Release Candidate 2. (Clearing cache first).

This bug still happens often, but its behavior is different, a little better.
Now it's no more necessary to clear cache. When the alert message appears, it's
enough to reload or click again the link or enter again the url, and the page is
loaded at this second try.

But if we try a third time (for example with the reload button or a link,
immediately or also when we start Mozilla the next time) the bug appears again
with the alert. The fourth try the page is loaded again, the fifth time we have
again the bug, and so on, alternating ok-bug successively. You can test this for
instance very quickly with the Reload button.

For example, testing with http://personasenaccion.info/tablon/ , a message board
that uses http headers to avoid cache and show fresh content. This is done with
the following .htaccess file (on an Apache server):

<FilesMatch "\.html$">
Header append Expires 0
Header append Cache-Control max-age=0
</FilesMatch>

About clearing cache, for some reason, the Mozilla's Cache folder is not emptied
until a re-start. Therefore, after clearing cache and starting again Mozilla 1.7
RC2, the page is loaded correctly from a link, and a file named "615500B0d01"
(21 KB) appears in the Cache folder of the Mozilla profile. This file contains
the HTML source of that page. It should not appear, according to the http
headers, but it appears.

When we try a second time the link to this page, or if we reload it, the bug
appears with the alert message, the page becomes a blank (white) screen and its
Cache file becomes a 0KB file with the same name "615500B0d01".

As said before, with the third try the page is loaded correctly, and we notice
that the Cache file recovers its size, 21KB.

That is to say, in brief:

0. After clearing cache, view OK, and new cache file 21KB.
1. First reload: The bug appears, blank view, and cache file 0KB.
2. Second reload: View OK, and cache file 21KB.
3. Third reload: Bug, blank, and cache file 0KB.
And so on...

Probably, if I'm not wrong, if the cache file was completely deleted instead of
becoming a 0KB file, then the situation would be similar to the initial after
clearing cache, and the bug would not appear again.
This bug happens to different people with different URLs, usually with dynamic
or no-cache or fast-expiring pages that one visits often. It happens even short
time after deleting the Mozilla cache, at the second visit to some sites. (Who
knows, maybe proxies are involved in this bug).

(A correction to my previous comment #116 : I think now that those commented
HTTP headers are more fast-expire than no-cache, in order to compare every time
if there is a new version of the page).

About my previous suggestion of deleting the cache file, I've just made some
testing and I think that in reality what shold be deleted (every time) are the
references to the affected pages in the files "_CACHE_00*".

With more testing, I've also seen that if we change the properties of the cache
file (for example that file "615500B0d01") to "Read Only", the bug does not
appear more for that specific web page. It does not matter if this change to
"Read Only" is applied either when the file is 0KB or for instance 21KB.

Deleting the "_CACHE_00*" files -or all the Cache folder- is only a momentary
pause for this bug, but a "Read Only" cache file permanently stops the bug for
the affected page. Of course this unmodifiable cache is not a solution at all,
but it might give some ideas about how this bug works.
(In reply to comment #117)
> (Who knows, maybe proxies are involved in this bug).

Yes, I've just verified that proxies are involved.

I'm testing with the current Mozilla 1.7 Release Candidate 2, where this bug
continues but is less serious than before. At least in my case, this bug appears
from the interaction between some proxies and Mozilla, only. Other browsers
(Opera, IE) are free from this bug with any proxy.

I see this bug almost continuously on the Mozilla browser (as explained on a
previous post) with pages using http cache headers and an ADSL connection that
uses "transparent" proxies (as you know, activated when the browser settings say
"Direct connection to the Internet"). If I change to another proxy (for instance
one of those listed at antiproxy.com) the bug disappears. It also disappears
using a dial-up connection.

As said, with Mozilla 1.7 Release Candidate 2 the bug is less serious: It is no
more necessary to clear cache, but a large number of people using Mozilla and
some proxies need to hit Reload half of the times for many links.

This is still a Mozilla bug, given that Opera and IE work fine with any proxy,
including that transparent proxy, a proxy used by some millions of people,
almost all the ADSL users of my country, for example.
New workaround: HTTP 1.0

Today I've received by email the best workaround that I've seen for this bug.
After getting permission from its author, I quote the note here:

* * * * * * *

"Noticed your recent comments in this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=123662

What is your preferences set to under Edit->Preferences-> HTTP
Networking/Proxy Connection Options?

If your proxy isn't 100% HTTP1.1 compatible, make sure that pref is set
to HTTP1.0. (Which is default in Opera and MSIE, but not in Mozilla). An
incompatible proxy might explain what you see.
see bug 38488. This used to be in the release notes but i can't find it
there anymore.

Just an idea.

Cheers - R.K.Aa."

* * * * * * *

I've been testing it with the current Mozilla 1.7 Release Candidate 2 for
Windows, and the bug disappears changing the setting to HTTP 1.0.

It works also with the mentioned proxy. (Interesting that this setting can be
necessary, given that Telefonica is a very big and old multinational
corporation; maybe too old...).

Another workaround is at jthompson's comment 57. In my case the compare cache
setting "When the page is out of date" works better for this bug than the
problematic "Once per session" that suffers this bug specially. But this is not
necessary with the HTTP 1.0 setting, an excellent workaround that seems to work
well with any of those preferences.

Anyway, I think Mozilla should be able to work with any proxy, even the old
ones. Probably it would be very easy with the solution already working in the
default configurations of IE and Opera, in order to deal with HTTP 1.0 or
partially 1.1 proxies.
Verified for Mozilla 1.7. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7) Gecko/20040623
Keywords: fixed1.7verified1.7
How can this be considered resolved? comment 118 says it has morphed a little bit. 
In any case the patch was just another hack.

I can reopen it if needed.
It's considered resolved because it's not supposed to be a meta bug covering
lots of similar issues, and bugs aren't supposed to morph.  An issue was
identified and fixed.  There are probably other issues with similar symptoms -
those should be separate, and specific bugs.
The bug summary is: '"File / cannot be found. Please check the location and try
again" when loading page'. It's the same bug that we saw before, with that alert
and blank web pages that can be seen with other browsers.

The patch of Mozilla 1.7 has improved some things, but it's not a complete fix.
Before the patch, the bug could be temporarily solved by clearing cache. After
the  patch, this is not necessary and it can be momentarily solved by reloading
the page or clicking again on the link.

Also, I think probably the bug is less frequent after the patch, but still
affecting some websites and some Internet connections and proxies. I guess
Mozilla developers and code contributors are waiting to see if more people keep
reporting the bug apart from me. I think this is reasonable, of course.

I must add, I've found that the previously mentioned workaround setting HTTP 1.0
works for some Internert connections but not for others, for example NTT ADSL
(Japan) that I'm using these days during a travel. In these cases, the best
workaround is to change the Mozilla settings to a different proxy in Edit ->
Preferences -> Advanced -> Proxies. (See lists of public proxies to try for
example at antiproxy.com). This is not necessary for other browsers not affected
by this bug, naturally (Opera, IE...).
Do we want a new bug, or should we reopen this bug?
If someone is interested in working on this further, it should probably be in
new bug(s).  There were actually three issues here:

1) There are unknown bugs somewhere that can corrupt the cache.
2) The error message when this happens is lousy.
3) Mozilla couldn't recover from a specific type of cache corruption.

This patch fixed #3 which resolved the problem for many users.  I'm not
convinced the proxy problem is really related although it does have the same
symptom.  There are a lot of networking code paths that come together here.  The
next level of fixing should probably be to track down who is corrupting the
cache in this case.
If someone is able to reproduce the error dialog, then I would be extremely
grateful to you if you would share your cache directory with me for testing
purposes.  If you mail your cache (compressed) to me, I will ensure that its
contents remain confidential.  Thanks in advance!

Let's please move further discussions to a new bug.  If you see this dialog,
please file a new bug.  Thanks!  (It might seem odd to do this, but it is the
usual process in these cases, because it greatly simplifies project management.)
(In reply to comment #126)
> If someone is able to reproduce the error dialog, then I would be extremely
> grateful to you if you would share your cache directory with me for testing
> purposes.  If you mail your cache (compressed) to me, I will ensure that its
> contents remain confidential.  Thanks in advance!
> 
> Let's please move further discussions to a new bug.  If you see this dialog,
> please file a new bug.  Thanks!  (It might seem odd to do this, but it is the
> usual process in these cases, because it greatly simplifies project management.)


Before opening a new bug, I was waiting to see if more users report this bug
after the 1.7 patch. I'm starting to think there must be something uncommon in
my Mozilla profile (years old) if I'm the only one still seeing this bug.

I saw the bug today with Mozilla 1.7. But, after clearing cache and upgrading to
Mozilla 1.7.1, I cannot reproduce the bug for the time being. However, I think
1.7.1 has nothing new about this bug. Also, I cannot reproduce it with another
computer using Mozilla 1.7 and the same connection (NTT ADSL, Japan).

If I see this elusive bug again the next days -maybe when I return to my
country- I will open the new bug and also I will send the cache and the http.log
to Darin (according to instructions from comment #6). Thank you very much.
Shortly time after my last comment, I was getting again the bug. And, after
quite a lot of testing and findings these days, I've opened -as advised- the new
bug 251121 (Summary: Remaining cases of "File / cannot be found. Please check
the location and try again" when loading page).

I've found a way to reproduce the bug anytime, also with other person's computer
and my computer at the same time, using the same ADSL connection and Mozilla 1.7
or 1.7.1 for Windows. I've explained the detailed steps in the new bug.

Therefore, if it can be reproduced on other computers, probably there is nothing
uncommon in my profile as I wrongly wondered recently. Also, I've found that the
HTTP headers from my comments 113 and 116 do not matter for this bug. Other
different factors are involved.

There are included as attachments to the new bug a very simplified webpage
test.html to reproduce it, and the http.log from a basic testing viewing the bug.

At Darin Fisher's request, I've sent my testing cache attached to an email as a
compressed file. There is not any need to keep this cache confidential: I
started by clearing cache. It can be shared with others if needed.

I hope this new bug 251121 can be useful to complete the still partial fixing of
this bug 123662.

Kind regards, and thank you very much as well for the important improvements
made already by Nick Allen's patch on Mozilla 1.7.
*** Bug 282960 has been marked as a duplicate of this bug. ***
*** Bug 279851 has been marked as a duplicate of this bug. ***
*** Bug 284773 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.