Hi grotlek, thanks for reporting and tracking this down!

In current git master (1.21wmf8) this function is located in the file
./includes/filebackend/FileBackendStore.php and you refer to this regex:

return preg_match( '/^[a-z0-9][a-z0-9-_]{0,199}$/i', $container );

grotlek wrote:

Hi Andre,

Yep, that's the one. It looks like it must have moved since 1.19. Sorry I don't have the code near me -- it's in a cold, dark and noisy room -- but from that, it looks like it's doing a case insensitive match anyways, so the only addition I'd suggest is a . character in the second square brackets. (I'm not sure whether I missed spotting that previously -- I was on a "just get it working" mission :-).

Of course, while this fixes my problem, I could not tell you whether:
a) it would have any unwanted side effects or implications elsewhere.
b) it would then make the regex cover all valid scenarios (i.e., do people use other characters?)

I was a bit hesitant from posting this at all, as I couldn't even figure out why it was fiddling with with the database name at all during file upload (it isn't using it in any obvious way -- the uploaded files don't go to a directory containing the DB name, for example). Given this, I'll back out at this point and let you more-knowledgeable folks handle it (if any change is warranted).

• Grotty.

44949 is another report of this bug. The regex is so strict to catch any container names that would break cloud storage backends that may use a '.' to separate namespaces. I just submitted a patch that leaves the strict regex in FileBackendStore but overrides it in FSFileBackend with a much more relaxed one that allows anything but '/'.

I suppose it would be appropriate to link to that commit: https://gerrit.wikimedia.org/r/83774/

FWIW due to how misleading the resulting error message is I think at least that should be improved, it is really confusing for end users particularly because searching for the error string leads to completely unrelated problems

Replacing dots with underscores would be an easy solution, as long as we can ensure uniqueness.

Swift container names can contain any UTF-8 character except /. S3 bucket names can only contain lowercase letters, numbers, and hyphens; the current FileBackendStorage container name rules already fail that. So there doesn't seem to be much to lose from making the rules less strict.

@Tgr any update?

https://scripts.mit.edu/trac/ticket/412 is a downstream ticket I was pinged about.

Change 83774 had a related patch set uploaded (by Legoktm):
filebackend: FS needn't be so strict with names

https://gerrit.wikimedia.org/r/83774

Change 219507 had a related patch set uploaded (by Aaron Schulz):
Allow "." in filebackend container prefixes

https://gerrit.wikimedia.org/r/219507

Change 219507 merged by jenkins-bot:
Allow "." in filebackend container prefixes

https://gerrit.wikimedia.org/r/219507

Change 83774 abandoned by Ejegg:
filebackend: FS needn't be so strict with names

https://gerrit.wikimedia.org/r/83774

@Tgr / @Ejegg: Hi, all related patches in Gerrit have been merged or abandoned. Is there more to do in this task? Asking as you are task assignees / patch authors. Thanks in advance!