(In reply to comment #0)

According to the config on

http://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist

Files like "DVC1234.JPG" should be blocked:

File:DVC[\d\s]+\.JPG  <reupload|errmsg=senselessimagename>  # DoCoMo

But here's one I could upload, as a non-admin.

http://commons.wikimedia.org/wiki/File:DVC9083427.JPG

Looks like the title blacklist entry is for reuploads while you're doing a regular upload. This bug seems invalid.

(In reply to comment #1)

Looks like the title blacklist entry is for reuploads while you're doing a
regular upload. This bug seems invalid.

Ah, just kidding. The "reupload" flag allows files to be reuploaded that match the blacklist, so this regular upload should've been blocked. Not sure why this didn't hit the blacklist.

I confirmed that it's not blocking regular uploads with names like "File:DVC222.JPG" as it should.

The title blacklist is working generally, though, e.g., http://commons.wikimedia.org/w/index.php?title=Http://&action=edit is appropriately blocked from creation.

Added to my TODO list to confirm on my trunk/wmf-deployment branches for this week

I can reproduce on trunk, as can Neil now, but seemingly nothing obvious has changed...

Computers suck

(In reply to comment #0)

The system does reject some commons patterns like DSC123456.JPG, but that is
because of yet another blacklist check
(http://commons.wikimedia.org/wiki/MediaWiki:Filename-prefix-blacklist).

No idea why we have 2 things doing the same thing though too.. :/

neilk wrote:

Any followup on the status of this bug?

If I recall correctly, did we find that it worked fine for regular uploads but not API uploads? Or did it not work at all?

I think this might be caused by r65898.

(In reply to comment #1)

(In reply to comment #0)

According to the config on

http://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist

Files like "DVC1234.JPG" should be blocked:

File:DVC[\d\s]+\.JPG  <reupload|errmsg=senselessimagename>  # DoCoMo

But here's one I could upload, as a non-admin.

http://commons.wikimedia.org/wiki/File:DVC9083427.JPG

Looks like the title blacklist entry is for reuploads while you're doing a
regular upload. This bug seems invalid.

The same just happened on it.wiki:

File:DSC.\d+\.JPG <reupload|errmsg=titleblacklist-custom-nomefile>

was bypassed by

https://secure.wikimedia.org/wikipedia/it/w/index.php?title=Speciale:File&user=Derek91

doing some test it works fine, these random fails sounds similar to abusefilters' bug #28154

I believe I fixed this in r90737 (But would love to have someone verify that, as some of these reports seem to suggest the problem was intermittent, where what I fixed was not).

It was caused by special:upload doing a $title->useCan('createpage'), where the extension was looking for a 'create' action check.

(In reply to comment #10)

I believe I fixed this in r90737 (But would love to have someone verify that,
as some of these reports seem to suggest the problem was intermittent, where
what I fixed was not).

It was caused by special:upload doing a $title->useCan('createpage'), where the
extension was looking for a 'create' action check.

Still here:

https://secure.wikimedia.org/wikipedia/it/wiki/File:DSC07963.JPG

I suppose it's just a synch matter.

(In reply to comment #11)

(In reply to comment #10)

I believe I fixed this in r90737 (But would love to have someone verify that,
as some of these reports seem to suggest the problem was intermittent, where
what I fixed was not).

It was caused by special:upload doing a $title->useCan('createpage'), where the
extension was looking for a 'create' action check.

Still here:

https://secure.wikimedia.org/wikipedia/it/wiki/File:DSC07963.JPG

I suppose it's just a synch matter.

Yes, the fix is in trunk, Wikimedia wikis run something significantly older.

I confirmed that this is fixed on my test install. I also agree that this should be pushed alive as soon as possible. Thanks, Bawolff!

(In reply to comment #12)

(In reply to comment #11)

(In reply to comment #10)

I believe I fixed this in r90737 (But would love to have someone verify that,
as some of these reports seem to suggest the problem was intermittent, where
what I fixed was not).

It was caused by special:upload doing a $title->useCan('createpage'), where the
extension was looking for a 'create' action check.

Still here:

https://secure.wikimedia.org/wikipedia/it/wiki/File:DSC07963.JPG

I suppose it's just a synch matter.

Yes, the fix is in trunk, Wikimedia wikis run something significantly older.

Wops I didn't realize it was still in trunk...so what about abuselog's bug? ;)

Wops I didn't realize it was still in trunk...so what about abuselog's bug? ;)

It appears unrelated :P

(In reply to comment #15)

Wops I didn't realize it was still in trunk...so what about abuselog's bug? ;)

It appears unrelated :P

I see but I hoped they were related... abusefilter is getting quite useless .__.

neilk wrote:

Thanks bawolff, that's excellent news.

I will test this myself later and then we'll discuss getting it into production.

neilk wrote:

This works for me too, and removing the fix in r90737 will cause the error to happen again, at least locally. Great.