41516 - HTTP download of a .zip file corrupts the disk cache (win32,mac)

Status: VERIFIED FIXED

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

Description

[John Morrison]

Overview Description:
  HTTP download of a .zip file corrupts the disk cache (win32,mac)

Steps to Reproduce:
1) On windows: delete mozregistry.dat, mozver.dat, and users50 
   (to get a default profile installed for a known state of the 
    cache structure).

2) start mozilla and go to :
      http://www.mozilla.org/projects/seamonkey/release-notes/index.html

3) click on the word 'Windows' in the sentence:
     "Macintosh, Windows, and i386 Linux users, please get a Talkback build."
   to download 
http://ftp.mozilla.org/pub/mozilla/releases/m15/mozilla-win32-M15-talkback.zip

4) save the file using the defaults offered (name and location).

5) - after the first download has occured, click the link again to
     download it again.
   - after the second download has occured, click the link again to
     download it again.
   - after the third download has occured, click the link again to
     download it again.

Actual Results:

After the first download:
    
    C:\Program Files\Netscape\Users50\default\Cache>dir /w
    
     Volume in drive C is PRIMARY
     Volume Serial Number is 3349-15FF
     Directory of C:\Program Files\Netscape\Users50\default\Cache
    
    [.]             [..]            CACHE.DB        [00]            [01]
    [02]            [03]            [04]            [05]            [06]
    [07]            [08]            [09]            [0A]            [0B]
    [0C]            [0D]            [0E]            [0F]            [10]
    [11]            [12]            [13]            [14]            [15]
    [16]            [17]            [18]            [19]            [1A]
    [1B]            [1C]            [1D]            [1E]            [1F]
             1 file(s)         65,536 bytes
            34 dir(s)     266,633,216 bytes free
    
    C:\Program Files\Netscape\Users50\default\Cache>du -s -k .
    5889    .
    
After the second download: 
    
    C:\Program Files\Netscape\Users50\default\Cache>dir /w
    
     Volume in drive C is PRIMARY
     Volume Serial Number is 3349-15FF
     Directory of C:\Program Files\Netscape\Users50\default\Cache
    
    [.]             [..]            CACHE.DB        [00]            [01]
    [02]            [03]            [04]            [05]            [06]
    [07]            [08]            [09]            [0A]            [0B]
    [0C]            [0D]            [0E]            [0F]            [10]
    [11]            [12]            [13]            [14]            [15]
    [16]            [17]            [18]            [19]            [1A]
    [1B]            [1C]            [1D]            [1E]            [1F]
    [TRASH00]       [TRASH01]       [TRASH02]       [TRASH03]       [TRASH04]
    [TRASH05]       [TRASH06]       [TRASH07]       [TRASH08]       [TRASH09]
    [TRASH0A]       [TRASH0B]       [TRASH0C]       [TRASH0D]       [TRASH0E]
    [TRASH0F]       [TRASH10]       [TRASH11]       [TRASH12]       [TRASH13]
    [TRASH14]       [TRASH15]       [TRASH16]       [TRASH17]       [TRASH18]
    [TRASH19]       [TRASH1A]       [TRASH1B]       [TRASH1C]       [TRASH1D]
    [TRASH1E]       [TRASH1F]
             1 file(s)              0 bytes
            66 dir(s)     265,584,640 bytes free
    
    C:\Program Files\Netscape\Users50\default\Cache>du -s -k .
    5889    .
    
After the third download (same directories):
    
    C:\Program Files\Netscape\Users50\default\Cache>du -s -k .
    11530   .
    
After the fourth download (same directories):
    
    C:\Program Files\Netscape\Users50\default\Cache>du -s -k .
    17171   .

etc.
 
NOTE: 'du' is the cygwin/unix command 'du' - disk usage; you can 
see by disk usage that one copy of the .zip file is being added to 
the disk cache each download

----------------------------------------------------------------------    

I do not see this occuring on linux (downloading the .zip file), but on
Mac I see something similar (downloading the .zip file): On the second
download the trash** directories are created and the original directories
are deleted (or a rename occurs) -- after that, I only get one copy _ever_
of the .zip file in the cache (which is correct, although the directory
rename is incorrect)   

----------------------------------------------------------------------    

Expected Results:
  No trash** directories created; at most one copy of the .zip file in the 
  disk cache (not one per download obviously)

Reproducibility: always, per steps to reproduce above

Build Date & Platform Bug Found:
  win32 2000060309

Additional Builds and Platforms Tested On:
  also occurs on mac mozilla 2000060408
  also occurs on win32 mozilla 2000060409
  does *not* occur on linux mozilla 2000060409

Comment 1

[neeti]

Reassigning to neeti.

Comment 2

[neeti]

I cannot reproduce the problem. I have tried this on windows, linux and the Mac.

In all three cases, I do not see the trash*** directories ever being created. I 
did downloads about 6 times on each platform. I see only one copy of the .zip 
file in the cache. The number of files and the disk usage remain the same after 
the first download, for each subsequent download, on each platform.

Neeti

Comment 3

[John Morrison]

As discussed with neeti, this still occurs in release builds on windows and
mac (tested 2000061608 win95 and 2000061518 mac). [This did not formerly
occur on linux, but bug #42750 blocks testing of this in current builds].

The behaviour is slightly different than it was when originally
reported:

windows: the 'trash**' folders still get created on the second
download of the binary file. However, I no longer get an additonal
copy of the downloaded file in my cache for each download episode. But
... if I restart the browser and download the same file, I do get a
second copy of that file in the cache. (Effectively, the first copy is
"marooned" in the cache).

mac: on the second download, the 'trash**' folders are created, but the
standard cache folders "00,01,02..." are removed (they no longer
exist).  On the third download, one zero-length _file_ called '00' is
created in the cache where the _directory_ called '00' used to exist.

Comment 4

[Gagan]

I had fixed the autogunzip problem around the time this magically got fixed. So 
this might no longer be an issue. For the remaining part I believe there already 
are other bugs. Am marking this as fixed. 

Comment 5

[Tom Everingham]

verified:
Win95 2000092508