Regression: {file_managed}.filename should NOT be binary (and case-sensitive by default)

My motivation to work on that change is that Drupal.org needed it, we have lots of filenames that vary only by case. This tells me that in the long run, it actually wasn't a "regression," something in Drupal 6 or maybe earlier allowed this to happen.

Changing this must keep the old urls working. An update function will have to change the conflicting filenames and add some sort of redirect so the old URL works.

In what cases would you want the file name and Uri to be different?

Patch makes sense :-), changing status, not sure about the policy on when to return a string on hook_update_N functions, so skipping RTBC.

Changing the version temporarily so the patch can be tested.

#3: 1691438-file-managed-revert-filename-binary.patch queued for re-testing.

I was thinking of the uri column, which has a unique key, and does need to be binary. This filename doesn't have any unique keys, so I guess it is fine.

BTW, Drupal.org has:

mysql> SELECT count(filename), count(DISTINCT filename), count(DISTINCT BINARY filename) FROM files\G
*************************** 1. row ***************************
                count(filename): 505528
       count(DISTINCT filename): 430648
count(DISTINCT BINARY filename): 432358

Adding patch for Drupal 8 to replicate the Drupal 7 patch.

I'm also a big +1 for rolling back the changes to filename. It's causing issues with the autocomplete widget in FileField Sources over here: #1691438: Regression: {file_managed}.filename should NOT be binary (and case-sensitive by default). I imagine it's the same problem Dave is having in Media, that users now have to know the case of their files in order to find them, unless we introduce a dreaded LOWER() wrapper in the query *shudder*. It would be a huge step backward after all the work in #279851: Replace LOWER() with db_select() and LIKE() where possible did to remove them. As far as I can tell, using the solution from that issue (replacing "= LOWER()" essentially with a LIKE statement) isn't going to work on these new binary columns.

Rerolled for new update number and including the line removal from the schema definition.

#20: file-managed-file-revert-1691438.patch queued for re-testing.

#24: file-managed-file-revert-1691438.patch queued for re-testing.

Same here, this will conflict with #1468328: Move file entity info, managed file, and file usage functionality into File module and I'd be kinda sad to have to re-roll that one again :)

Tests passed, looks good patch and already previously marked RTBC.

Ok, gotcha. So we were a little over-zealous with our fix at #966210: DB Case Sensitivity: system_update_7061() fails on inserting files with same name but different case. Sorry about that.

Looks like everyone here, including drumm, is on the same page about the fix, so committed and pushed to 8.x. Moving down to 7.x for backport. Once that's done, we'll probably have to move back to 8.x again to remove the update function.

D7 patch.

Looks fine.....

Great, thank you!

Committed and pushed to 7.x, now back to 8.x to get rid of the update function. I think we can reduce the priority of this issue now, since this is just clean-up.

Thank you so much for fixing this problem! My users were getting pretty antsy about file search being case sensitive, and I had no idea how to help them.

A patch to remove the update function.

I thought our practice was to leave the update function but replace it with a comment. But checking our current approach, we just vaporize the entire update. That's why we don't have system_update_7010() or system_update_7019(). Patch looks complete and prevents D8 upgrades from re-regressing when updating from D7.

UPDATE FUNCTION: VAPORIZED.

Awesome, thanks a ton. Committed and pushed to 8.x. Happy to see this sucker marked fixed. :D

:)

20: file-managed-file-revert-1691438.patch queued for re-testing.

Fix media tag.