Comment 42 for bug 1203240

(In reply to comment #31)
> (In reply to comment #26)
> > > Yep, this will purge the old files. I have a concern though for the files that fall under the GST_WARNING of line 1377 of not being able to unlink. Should we assume that is is very unlikely and forget (and trust distros to purge this from time to time)? Btw, if it is so unlikely, we can tag the decission as UNLIKELY().
> >
> > Michael would say that WebKit should try hard to clean its own files. I
> > don't think distros are going to mess with the contents of the user home
> > dir, even for the .cache dir. Thanks for the UNLIKELY() suggestion, btw.
>
> I think I wasn't clear here. Line 1377, if the regular unlink fails (not the
> purge one, the regular) we are leaking them (under /var/tmp/).

Trying to purge leaked files in the new /var/tmp location doesn't make sense. If the files couldn't be deleted right after creation in the first place (because of a race condition with permissions, where some malicious (root?) process changes the permissions in the milisecond that the file is visible), then ther's no point on trying to delete the file later: the deletion will also fail for the same reasons it failed initially.

Purging files in the old location still makes sense, because with the old implementation more time passed from file creation to file deletion (eg: 2h until the movie finishes being played) and the probability of a crash or kill (the only reason why the file would have been leaked) was higher.