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.
do you have a testcase?
> 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/
> 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.
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?
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.
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.
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-22.214.171.124-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).