Thanks for the clarifications

• fix the variable typo;

This problem has gone away due to other recent work.

• fix the documentation mistake;

Can do.

• rename buildFromFileDataOrHash(...) to something more clear, like newTemporaryFileFromData(...).

IMHO, the race condition should be fixed. Though I suppose it will be very rare, if the TTL/expiry isn't adjusted when a temporary file is 'retrieved' rather than 'created', 7 days (default) after creation, if the file is retrieved an about-to-expire file will be returned; in fact, an already-expired file could even be returned if the garbage collector hasn't run yet. If the GC then manages to run between the file generation and the browser requesting the referenced file, of course it will break. It's a less severe breakage, at least in the icon case, because it only breaks the icon selection page, but the crystal ball is foggy regarding future applications. I guess in any conceivable case the user would just refresh and it would work. But intermittent failures are horrid, make the software seem flaky/unreliable, and are hard to track down. IMHO, better to fix the race condition now that we've found it. If client code expects a file to stick around for a certain time, it should do so, not pull the carpet out from under it.

I could amend this patch to:

• remove buildFromFileDataOrHash entirely and always create new files; they would still share storage, of course, but it could churn through file IDs faster than desirable, perhaps; OR
• extend the expiry only, never to make files permanent (and rename the method); OR
• do some kind of hysteresis thing, where the expiry is only extended if it falls short by a significant margin, but I think that's overkill.

Please let me know if you're amenable to any of those ideas.