From nsICachingChannel: 123 /** 124 * Get the "file" where the cached data can be found. This is valid for 125 * as long as a reference to the cache token is held. This may return 126 * an error if cacheAsFile is false. 127 */ 128 readonly attribute nsIFile cacheFile; If we're not holding the cache token alive, this file might be removed from the disk. The easiest way forward here is probably to make nsDOMFile able to hold onto an opaque nsISupports pointer, and then give the constructor the cacheToken from the caching channel.
Also, we have to ensure that slices hold onto the cache token as well.
Masatoshi: Do you think you'd be able to get to this? I think we should fix this for FF6 or disable the feature.
Created attachment 537172 [details] [diff] [review] patch Please apply this on top of the patch of bug 661582.
Created attachment 537305 [details] [diff] [review] patch v2
Created attachment 537313 [details] [diff] [review] patch v2.1
Comment on attachment 537313 [details] [diff] [review] patch v2.1 Looks good, but add the new aCacheToken argument to the first constructor instead, as per the review of bug 661582.
Created attachment 540336 [details] [diff] [review] patch v3 Rebased to the latest bug 661583 patch. Carrying forward r+.
Created attachment 543237 [details] [diff] [review] Reordered patch This is Masatoshi's patch reordered to not depend on the patch in Bug 661582.
Comment on attachment 543237 [details] [diff] [review] Reordered patch Drivers, we will want to take this patch for Firefox 6 to ensure that a File object's actual file on disk is not removed from the cache depending on the whims of GC behavior. I believe the risk of this patch is very low.
Comment on attachment 543237 [details] [diff] [review] Reordered patch Approved for releases/mozilla-aurora. Please land asap before 2011-07-05 @ 9:00 am PDT.
6 years ago
Backed out from mozilla-central during investigation of Android browser-chrome test failures: http://hg.mozilla.org/mozilla-central/rev/00bb08972e46
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0 Could you please provide a test case in order to have this issue verified?