Closed Bug 79983 Opened 23 years ago Closed 23 years ago

Old file data not over-written when file on server is changed and new file is smaller than old one

Categories

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

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: andrew, Assigned: gordon)

References

(
URL
)

Details

(Keywords: top100)

Attachments

(2 files)

Ignore the raw image data at the bottom - that was my fault.
1.33 KB, text/html
Details
image of results of tester described in my last comment
15.95 KB, image/png
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515

In the page at ns1.2mx.co.uk/2qqqpics at the bottom of the page I got old stuff
from the previous version of the file still there when I pressed reload to get
the new version of the file. The new file was smaller than the old one and the
content which made up the difference was still output to the browser window.
Presumably this is due to enhancements in the "isModified" detection.

Reproducible: Always
Steps to Reproduce:
1. Create a file with some text and images perhaps.
2. View it over the network in mozilla.
3. Change the file by deleting stuff from the middle of the file.
4. Reload the file and see how old **** is stil present.

Actual Results:  Old file data present in output stream.

Expected Results:  Normal file output with no old file data.
A partial fix for this was landed on Monday (2001-05-07), which corrects the size 
the cache thinks the entry is.  However, the file containing the cached data is 
not truncated yet.  That will should get corrected with the landing of Disk Cache 
Level 2 (bug 72507), which has a target milestone of 0.9.1.

I'm going to set the target milestone to 0.9.2, but make it dependent on bug 
72507.  It should still get fixed for 0.9.1, but since it doesn't represent 
separate work we don't need to track it for that release.
Status: UNCONFIRMED → ASSIGNED
Depends on: 72507
Ever confirmed: true
Target Milestone: --- → mozilla0.9.2
Depends on: 81724
I'm seeing something like this with Mozilla/5.0 (X11; U; Linux 2.2.18 i686;
en-US; rv:0.9+) Gecko/20010523, buildid: 2001052308.
In my case, it's a cgi program, and it shows up best when hitting back.
For example: start at cgipage1?show=short go to cgipage1?show=long
then hit back.  
I can't reproduce it at will yet, but it happens to me on an intranet
application several times a day.  a shift-reload makes it redraw properly.
The file in the cache directory ends up with the extra stuff at the end as well.
I can confirm Chris Hiner's comments on build 2001053106 (Linux -sea install). 
Bug 72507, which is now marked closed, doesn't seem to have fixed this case.

Is OS more appropriately set to "All", given the two Linux reports?
Priority: -- → P3
I can reproduce something similar on Linux -- if I shorten a file, reload it,
and then click on a link and go back, I see the old contents at the end.  All/All.
OS: Windows 2000 → All
Hardware: PC → All
Here's a simple demonstration of this:
1. go to http://didntduck.org/cgi-bin/79983.pl
2. Hit reload
3. Click where it says "click here"
4. Hit back
5. Notice leftover old text at the bottom

This is just a simple cgi program that stores a counter in a cookie, and then
decrements it by 20 each time the page is loaded.  It draws counter number of
lines in a table.  When it hits 0, it starts back at 80.

I'll also attach a png I created from printing it, which shows what appears on
screen (and on paper).
Last tested on Linux trunk build 2001060508.
*** Bug 84518 has been marked as a duplicate of this bug. ***
*** Bug 84571 has been marked as a duplicate of this bug. ***
*** Bug 84852 has been marked as a duplicate of this bug. ***
*** Bug 82816 has been marked as a duplicate of this bug. ***
*** Bug 85017 has been marked as a duplicate of this bug. ***
*** Bug 85511 has been marked as a duplicate of this bug. ***
*** Bug 86469 has been marked as a duplicate of this bug. ***
*** Bug 84598 has been marked as a duplicate of this bug. ***
*** Bug 86919 has been marked as a duplicate of this bug. ***
Adding mostfreq at 9 dups (one too early but with 3 new ones last week the
dynamics is right)
Keywords: mostfreq
Lets try these on the trunk and if they do well there we can try bringing them 
back in the 0.9.2 branch.
Keywords: nsBranch
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Priority: P3 → P2
*** Bug 87462 has been marked as a duplicate of this bug. ***
*** Bug 88007 has been marked as a duplicate of this bug. ***
Just thought I'd mention that this can severely break sites when the file in
question is .js
Keywords: 4xp, top100
*** Bug 88104 has been marked as a duplicate of this bug. ***
*** Bug 88362 has been marked as a duplicate of this bug. ***
*** Bug 88867 has been marked as a duplicate of this bug. ***
*** Bug 89492 has been marked as a duplicate of this bug. ***
*** Bug 89686 has been marked as a duplicate of this bug. ***
*** Bug 90016 has been marked as a duplicate of this bug. ***
*** Bug 91163 has been marked as a duplicate of this bug. ***
*** Bug 91463 has been marked as a duplicate of this bug. ***
This bug has been fixed on the branch with the recent checkin for bug 86474. 
We'll need to land that patch on the trunk as well.

*** Bug 91444 has been marked as a duplicate of this bug. ***
*** Bug 91869 has been marked as a duplicate of this bug. ***
*** Bug 91951 has been marked as a duplicate of this bug. ***
*** Bug 85127 has been marked as a duplicate of this bug. ***
*** Bug 80374 has been marked as a duplicate of this bug. ***
*** Bug 89509 has been marked as a duplicate of this bug. ***
*** Bug 92385 has been marked as a duplicate of this bug. ***
*** Bug 92364 has been marked as a duplicate of this bug. ***
The patch for bug 86474 has been landed on the trunk.  We still need to fix
various Unix platforms, but we can track that in bug 86474.

Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 90444 has been marked as a duplicate of this bug. ***
*** Bug 86430 has been marked as a duplicate of this bug. ***
*** Bug 92600 has been marked as a duplicate of this bug. ***
verified fixed late last year, no new dupes in over six months
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: