We would want to take into account the following factors:
1. Arbitrarily changing SFNs will break existing wineprefixes that save SFNs in configuration files and registry. At minimum, we should have a soft-rolling mechanism that keeps the old hash algorithm for existing prefixes.
2. Changing the discriminator length merely reduces the probability of collision, but does not fundamentally eliminate it. Consider the following table (generated with [sfn_birthday_paradox.py](/uploads/c2d0766f51ec86b96652c0b063122efb/sfn_birthday_paradox.py)):
| # of possible hashes | maximum # of files until collision of ~50% probability | | -------------------: | -----------------------------------------------------: | | 2<sup>15</sup> | 214 | | 2<sup>16</sup> | 302 | | 2<sup>17</sup> | 427 | | 2<sup>18</sup> | 604 | | 2<sup>19</sup> | 853 |
2<sup>18</sup> is undeniably an improvement, sure, but it does not rule out the possibility that someone else will encounter a similar problem in the future. What would we do in that case?
3. Using arbitrary charset not used by Windows may lead to unforeseen compatibility problems.