Closed Bug 123662 Opened 23 years ago Closed 21 years ago

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

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: robert, Assigned: nallen)

References

Details

(Keywords: verified1.7)

Attachments

(14 files)

Screenshot of Moz and IE both pointing at bugzilla.mozilla.org - w/ only IE working
114.41 KB, image/jpeg
Details
Log file with output from a repro of this error.
251.15 KB, text/plain
Details
ScreenShoot of my pc when I try to open http://windows.zdnet.it
70.08 KB, image/jpeg
Details
testcase http://bugzilla.mozilla.org/show_bug.cgi?id=123662 :-)
209.67 KB, application/octet-stream
Details
Log file exhibiting error
2.62 KB, text/plain
Details
The file /index.php?c=4 cannot be found
40.42 KB, image/png
Details
The file /index.php?c=4 cannot be found - Log
184.14 KB, application/octet-stream
Details
The file / cannot be found - Fark.com
8.82 KB, text/plain
Details
File / cannot be found - FARK.com
2.92 KB, text/plain
Details
http failure log
41.23 KB, application/zip
Details
http error log
6.78 KB, application/zip
Details
Error log of the error. See comments for details
67.77 KB, application/zip
Details
Doom records with corrupt storage
882 bytes, patch
darin.moz
: review+
darin.moz
: superreview+
asa
: approval1.7+
Details | Diff | Splinter Review
Windows cannot find "http://www.foxnews.com/" Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.
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: 21 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.7 → verified1.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.

Attachment

General

Creator:
Created:
Updated:
Size: