In fact, I have 96 copies of the same jar file in my TestPilotExperimentFiles directory. Named week-life-1.jar, week-life-2.jar, all the way up to week-life-96.jar. This is a Bad Thing. Evidently the code that tries to detect whether the file has changed before downloading it isn't working, and it's downloading every time. Also, apparently when it saves a new version, it doesn't overwrite the previous version, but actually changes the name to avoid the conflict. So we need to fix the logic of dont-download-unless-changed, and if it has changed we need to delete the old one before saving the new one.
The failure of the If-Modified-Since logic is a direct result of the newly downloaded file not overwriting the original: the original "week-life.jar" remains unmodified, and its modification date is the one used for the "If-Modified-Since" header... the newly downloaded one becomes "week-life-1.jar" which means that no matter how many times it downloads "week-life.jar", the modification date of "week-life.jar" never changes.
This line of code was the culprit: jarFile.createUnique( Ci.nsIFile.NORMAL_FILE_TYPE, 600); Of course, if I tell it to createUnique, it creates a unique file! Duh.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.