157853 - save image file cache sillyness

Status: RESOLVED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[Tim Connors]

On Tru64, anything above 0.9.9 saving an image file to disk gives a popup
errorbox:
Download error:
"/blah/Cache/BHAHAHAfoo". Seems to save the file OK though.

Inicdentally, on version 1.1a saving any file is insanely slow on both linux and
tru64. It sits spinning, as soon as you click OK on the save dialog. It was
instant on 0.9.9, and as such, am forced to go back.

Comment 1

[Matthias Versen [:Matti]]

-> invalid

We don't accept bugs from 0.9.9 (only from the latest milestone)

Comment 2

[Tim Connors]

Erm - "anything above 0.9.9" implies latest milestone (Is 1.1a latest
"milestone", or is 1.0 latest milestone? I tested them both, and they both failed.).
Extra information: I also cleared out my profile data (which I shouldn't have to
do, dagnamit!), and the problem is still there....

BTW - I lied, I am using 0.9.8 to get rid of the cache (and slowness) silliness,
not 0.9.9, so for all I know, the problem could have been introduced anywhere
between 0.9.9 and 1.0-rc?.

Comment 3

[Matthias Versen [:Matti]]

-> File Handling

Comment 4

[Vidar Haarr (not reading bugmail)]

Reporter: does this problem still occur on a recent nightly ?

Comment 5

[Tim Connors]

I'm afraid I am unable to compile the nightlies  - only 2 gig quota, and a
rather important project to do :(

I'll get back to when another Tru64 binary is released.....

Comment 6

[Tim Connors]

Finally found a binary for 1.1b (Tru64 has some trouble being supported :).

It shows the same problem with the download error.

Note that I can't use a nightly because the last one to be compiled for OSF was
in March, however, I suspect, since you posted before the 1.1b version was
released, that maybe you were expecting it to be fixed for 1.1b as well as the
nightlies?

To elaborate on the problem, the error box has a title of "download error" and
the only text in the box is the name of a file in the cache directory. It
doesn't actually say what is wrong with that file, and the file truly does exist
on the filesystem.

Comment 7

[Vidar Haarr (not reading bugmail)]

Good you could test this with a more recent build..

Since I'm a Win32 guy, you'll need to get someone else to look into your
problem. Hopefully, Bill or Sairuh will get to it..

One thing you could do is visit irc.mozilla.org/#mozilla, and talk to the people
there.. maybe someone could help you.

Comment 8

[Tim Connors]

Build 1.1 vanilla:
Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.1) Gecko/20020828

Steps to reproduce:

Use your default setup, or if paranoid, mv your .mozilla directory to
.mozilla-old, and start mozilla, and setup an old profile from netscape.
Proabbly does the same thing from a completely new empty profile. Point being,
that the Cache directory is most certainly new and uncorrupted etc.

Using Tru64, as soon as I try to save an image (on my home page), I get the
download error, just reporting "/home/office/.../.mozilla/.../Cache/68A2DE....."
No mention of what is wrong with that file, which does now exist on my
filesystem, with rw permissions for me. File is succesfully saved to desintation
directory.

Download manager window pops up, despite me not having asked for it, saying
"progress: failed"

Fault did not exist in 0.9.9, seemed to appear somewhere in the 1.0-rc's.

Comment 9

[Andrew Schultz]

It looks like you are seeing something that absolutely nobody else does (that's
why they keep asking you to try newer builds! :)).

Anyway, is there anything unusual about the setup of your machine/Mozilla? 
Perhaps your home directory is NFS mounted?  Are there any files in your cache
directory?  Does this only occur with images?

Does this happen if you 1) open a page 2) clear the disk cache 3) save an image

This sounds like "cache" more than "file handling"...

Comment 10

[Tim Connors]

Interesting. I was almost thinking I was the only person in the world to be
using mozilla under Tru64 ;)

My home diretory is NFS mounted, with the swerver being a Linux machnine. We had
to disable filelocking on the Tru64 clients, for reasons unknown to me. This has
caused problems before (our NFS server used to OOPS, when netscape 4.77 tried to
open mail, related to filelocking problems).


From a fresh profile:
ls -lA /home/office/tconnors/.mozilla/Default\ User/wv4bqwxd.slt/Cache/
total 48
drwx------   2 tconnors pulsar       4096 Sep  2 13:22 .
drwxr-xr-x   4 tconnors pulsar       4096 Sep  2 13:23 ..
-rw-------   1 tconnors pulsar      12186 Sep  2 13:22 727A1989d01
-rw-------   1 tconnors pulsar       4042 Sep  2 13:22 7C4C705Ed01
-rw-------   1 tconnors pulsar       1825 Sep  2 13:22 B75DCE4Cd01
-rw-r--r--   1 tconnors pulsar       5632 Sep  2 13:23 _CACHE_001_
-rw-r--r--   1 tconnors pulsar       4096 Sep  2 13:22 _CACHE_002_
-rw-r--r--   1 tconnors pulsar       4096 Sep  2 13:22 _CACHE_003_
-rw-r--r--   1 tconnors pulsar       4096 Sep  2 13:22 _CACHE_MAP_

The guilty file is 727A1989d01 (a JPG image).

When I clear the cache, the _CACHE_* files remain, and I try to save the image
again, and it comes up with another 'download error' dialog box twice. This time
the error message is "astronomy.swin.edu.au" - the domain name of the file - but
not the complete URL! Identical message box both times it pops up. Again, file
appears at destination OK, file is in CAche directory OK, progress meter now
doesn't actually finish - it looks like it is sitting there happily at 100%, not
actually saying "completed" or "failed".

If I try to save this page, again, "failed", this time the error box gave a
cache filename of one of the GIF images. All the files are there, and there are
several images on this bugzilla page, so I don't know whether it had a problem
with just the images, or with the first or last thing it downloaded. 

Next test: a page with  no images on it. Geez, this hard to come by ;)
Wahoo! It didn't "fail"!
So, image handling under Tru64 with NFS home directory, with bogus filelocking
is bogus :)

Need any more info?

Comment 11

[Andrew Schultz]

> Need any more info?

Probably, but I don't know what else to ask.  Dumping this in Cache as "File
Handling" just seems to be the victim here.

Comment 12

[gordon]

It sounds like the cache is working just fine.  File handling is reporting
errors...why?  And why is it only a problem with pages with images?

Comment 13

[Kai Lahmann (is there, where MNG is)]

Reporter: Can you reproduce this bug with a recent build of Mozilla (for
example, 1.4 RC1)? If so, then please comment again with details. If not, then
please resolve this bug as WORKSFORME. Thanks.

Comment 14

[Tim Connors]

marking as worksforme as requested, but I can't actually test - I no longer have
access to an alpha machine