Use strcoll_l() for locale-independent comparisons

[dan-rigdon-bel]

The update code uses the compareFiles function to determine the sort order of file names in a directory, which is then compared with a list of files in the Sparkle update info. If the list of files of a directory from Sparkle's update is different than what is on disk, the Sparkle abandons the update and does a full download. This bug would prevent Sparkle from updating properly when the file lists are calculated on an English language system, but then checked on a destination Japanese system.

The fix is to use strcoll_l(), which is locale-independent, when comparing file names for sorting. This will ignore any locale changes the host application has made that could potentially affect Sparkle's sort order.

(Insert summary of your pull request here)

Fixes # (issue)

Misc Checklist:

• My change requires a documentation update on Sparkle's website repository
• My change requires changes to generate_appcast, generate_keys, or sign_update

Only bug fixes to regressions or security fixes are being backported to the 1.x (master) branch now. If you believe your change is significant enough to backport, please also create a separate pull request against the master branch.

Testing

I tested and verified my change by using one or multiple of these methods:

• Sparkle Test App
• Unit Tests
• My own app
• Other (please specify)

(Describe all the cases that were tested)

macOS version tested: [place version here]

[zorgiepoo]

Thank you. I assume cases where this fails is when files have some sort of non-english or accent characters or some such in them (otherwise I am curious what a reproducible case is). I'm also guessing using the c locale is somewhat equivalent to using strcmp(). Either way, change looks good.

[dan-rigdon-bel]

I assume cases where this fails is when files have some sort of non-english or accent characters or some such in them

Exactly right. We hit this bug with internationalized file names in Japanese.

[zorgiepoo]

I should have asked, do you still have an example of two filenames that don't sort the same way on en_US vs ja_JP?

[dan-rigdon-bel]

I should have asked, do you still have an example of two filenames that don't sort the same way on en_US vs ja_JP?

I'm sorry to say that I do not. Reversing our changes to get the list would be challenging.

[zorgiepoo]

I could probably figure it out if the app was publicly available, but it's not a big deal either way.