195637 - using StreamAsFile cannot always find disk file (cache deletes file larger than disk cache)

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[tenthumbs]

I found this on Linux using plugger but it doesn't seem limited to plugger.

If a plugin uses StreamAsFIle _and_ the file is larger than the disk cache 
limit, then the cache deletes the file before the plugin can use it. The plugin 
just has a path to a non-existent file.

I thought this was a known problem but I couldn't find another bug on it. If
it's a dup, sorry for the spam.

Comment 1

[Peter Lubczynski]

do you have a testcase?

Comment 2

[Andrew Schultz]

> do you have a testcase?

set disk cache size to 50KB and try to load any avi/mpg (via http), etc that
plugger is configured to handle.

if disk cache is disabled or set to 0 KB, Mozilla puts the file in /tmp/plugtmp/

Comment 3

[tenthumbs]

> do you have a testcase?

You can also leave the cache at the default 50MB and just transfer via 
http a file larger than that. It happens with plugger and large audio 
files but can occur with any mime type. I can see the file being stored 
in the cache directory and its name is handled to the plugin but the 
cache deletes the file before the plugin can open it.

Comment 4

[Peter Lubczynski]

Plugin code can do the caching itself as is done in the /tmp case. 

I wonder if there is a way to tell if the request will fit in the cache?

Comment 5

[Darin Fisher]

hmm... yuck.  this is a difficult problem to solve.  HTTP downloads only
sometimes include a Content-Length header, so often times you don't know the
length of a data stream.  perhaps the right solution is to set a flag so that
the hard limit on the cache can be temporarily exceeded.  the large file marked
with this flag would not have to displace other files, and we could delete it as
soon as possible.  i can't think of any other way to deal with this problem.

Comment 6

[WD]

Is bug 229984 related to this?
The cache does grow to allow HTTP downloads of files larger than the cache's max
size, but once that occurs the disk cache can often be put in an unusable state.

Comment 7

[Jan Kasprzak]

Hello,

any updates wrt. this bug? I have just ran into it in the latest-greatest Fedora 10/x86_64, when downloading a large PDF file for opening. Apparently, mozplugger-helper deletes the file and then runs evince (my PDF viewer) with a nonexistent file as an argument:

$ ps ax|grep moz
32106 ?        Ss     0:00 mozplugger-helper 1304,1,10,98566154,0,0,1422,996 evince "$file"
32107 ?        Sl     0:00 evince /home/kas/.galeon/mozilla/galeon/Cache/8B4AB048d01
$ ls -l /home/kas/.galeon/mozilla/galeon/Cache/8B4AB048d01
ls: cannot access /home/kas/.galeon/mozilla/galeon/Cache/8B4AB048d01: No such file or directory

I have found that when the same file is downloaded via https+basic authentication, it is displayed correctly (the file is downloaded into /tmp/plugintmp/plugin-<origfilename>.pdf, which is a security hole tracked by bug #164842, but at least it opens the file).

My software is: Fedora 10/x86_64, xulrunner-1.9.0.6-1.fc10.x86_64, firefox-3.0.6-1.fc10.x86_64 (the bug is also present in other gecko-based btowsers such as galeon-2.0.7-5.fc10.x86_64).

Comment 8

[Wayne Mery (:wsmwk)]

like bug 1197801?

Comment 9

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.