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):

Minor clarification.

See also note in https://we.phorge.it/D25475#inline-3542 - looks like "creating a transformation" is done in many places.

In D25051#15888, @valerio.bozzolan wrote:

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

You are concerned for performance reasons because it doesn't limit the results. Right?

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

Gotcha. Probably this is generating the attachment transactions but should be "ignored on no effects":

This feature is not complete also for Conpherence AFAIK

My steps to reproduce are wrong / unclear / not always happening.

Other edges have probably been eliminated in the past. For example this one:

I had communicated these upstream (almost exactly a year ago~) and some helpful information was provided

For others reading this thread: there's some discussion going on in the thread of the patch linked above, D25419.

PhabricatorFileAttachmentQuery seems to eagerly load the object relation, however since the DestructionEngine extensions run after the object is already deleted, this fails and nothing is returned in the query. Changed to LiskDAO loadAllWhere, which also seems to use less queries in general (due to not eagerly loading), so changed the query in PhabricatorFile as well. Changed mpull to foreach per suggestion.

Please share the output of this:

In T15498#11487, @valerio.bozzolan wrote:

OK I can reproduce now. I was missing the php-gd extension for some reasons.

OK I can reproduce now. I was missing the php-gd extension for some reasons.

I'm trying to reproduce this, but in my local installation I do not have any allowed file formats. I also do not remember how to make that list available.

In T15326#11073, @Cigaryno wrote:

Do you mean PHP 8.0 or PHP 8.1? I'm confused.

Do you mean PHP 8.0 or PHP 8.1? I'm confused.

For the records, I had the same experience when deleting a repository via ./bin/remove destroy rESHP for Unknown edge constant "25" (not 26 as mentioned in the task title) in downstream https://phabricator.wikimedia.org/T119588

Another use case: Drag & Drop on a new Object description, even if the Object is not already created, should attach by default to it.