The current workaround I'm proposing is just:

(we can probably keep this ticket open, so that we have the 2nd part on the backlog. I'm pretty sure we want it to happen "eventually".)

Feel free to show something early :) That would attract more attention than the Discussion Needed tag I bet

Wrote the code for the first phase :p

Sounds good to me :p

We can also ship this feature in two phases, so, first, adding the option files.maximum-file-size, and then the second one when it's ready or requested lol

Yeah, I agree, though I would then only work on implementing files.maximum-file-size because we don't really care that much about adding exceptions to the rule (as far as I know lol)

Uh, that would be so good. So you can say "When the moon is full".

Sounds reasonable.

I like your option names. I like to specify PHIDs and not numeric IDs so it's more portable against import/exports 👍 Let's add Discussion Needed to attract some +1 or nice suggestions.

Thanks :)

Just for the glory of the archive. I've tested this feature in production before landing.

Yep. In all cases it's at least a full-table-scan on file_attachment. Probably a bit more RAM-efficient with the NOT EXISTS thing since it does not need to have all file PHIDs in memory.

Tested again. Double-accept.

We can take inspiration from Phame (?)

I'd be worried about DB performance running such a query as our DB has dozens of millions of files... (This is basically SELECT COUNT(*) FROM file_attachment fa WHERE fa.filePHID NOT IN (SELECT f.phid FROM file); in my understanding?)

Unrelated but @aklapper I'm curious about the situation in WMF. If you can maybe report something like this:

git rebase master

A bit more than Normal, since it reflects on a database with orphan elements that creates "ghosts in the UI".

Relevant old upstream comment (from an unrelated task) that describes this problem as "ghosts in the UI":

Thanks again. My only concern is that, if somebody has a 1 trillion file(s) then the patch may lock the involved tables for an unexpected long amount of time, and you cannot really undo, without causing a massive implicit rollback.

git rebase master

Just as clarification for myself (maybe already obvious to others):