4 ms·

> But here, normalization caused this issue. Nope, the lack of normalization on both accounts by the SMB server caused the issue. It could have normalized befo

> But here, normalization caused this issue. Nope, the lack of normalization on both accounts by the SMB server caused the issue. It could have normalized before emitting but it definitely should have normalized on receiving for comparison.

silon42 5y ago
At least it should perform validation and reject the NFD form and force the client to normalize to NFC?
- rurban 5y ago
  NFD is fine when you dont have much time and can afford the space. NFC is about 3x slower and smaller. Forcing clients never works. Be tolerant what you accept and strict what you write. In the case of C++23 enforcing NFC my mind is twisted. It would allow heavy tokenizer optimizations, but this is an offline compiler, where you don't really need that. The problem are the compatible variants, NFKC and NFKD. But then you have usecases where you need them, and more to actually find strings. Levenshtein should not be the default when searching for strings.
B-Con 5y ago
I think that in the ls->read workflow, Nextcloud shouldn't normalize the response from SMB and should issue back to SMB whatever SMB returned to Nextcloud.
- guerrilla 5y ago
  According to Unicode, it should be allowed to and the SMB server should be able to handle it. That's kind of the point of normalization, they're meant to be done before all comparisons so that exactly this doesn't happen. Your suggestion is just premature optimization, i.e. eliminating a redundancy.
  - int_19h 5y ago
    Unicode doesn't say anything about what "should be allowed to" with respect to an unrelated protocol. If the protocol says that filenames are sequences of 16-bit values that have to be compared one by one, then that's what it is.
    - guerrilla 5y ago
      It does say that if comparisons are being made then... and comparisons are being made, so yes, it does.
      - int_19h 5y ago
        If comparisons are being made of Unicode strings, sure. Does the protocol actually defines the identifier in question as a Unicode string, though? Or as an array of 16-bit ints?

silon42 5y ago

At least it should perform validation and reject the NFD form and force the client to normalize to NFC?

rurban 5y ago
NFD is fine when you dont have much time and can afford the space. NFC is about 3x slower and smaller. Forcing clients never works. Be tolerant what you accept and strict what you write. In the case of C++23 enforcing NFC my mind is twisted. It would allow heavy tokenizer optimizations, but this is an offline compiler, where you don't really need that. The problem are the compatible variants, NFKC and NFKD. But then you have usecases where you need them, and more to actually find strings. Levenshtein should not be the default when searching for strings.

B-Con 5y ago

I think that in the ls->read workflow, Nextcloud shouldn't normalize the response from SMB and should issue back to SMB whatever SMB returned to Nextcloud.

guerrilla 5y ago
According to Unicode, it should be allowed to and the SMB server should be able to handle it. That's kind of the point of normalization, they're meant to be done before all comparisons so that exactly this doesn't happen. Your suggestion is just premature optimization, i.e. eliminating a redundancy.
- int_19h 5y ago
  Unicode doesn't say anything about what "should be allowed to" with respect to an unrelated protocol. If the protocol says that filenames are sequences of 16-bit values that have to be compared one by one, then that's what it is.
  - guerrilla 5y ago
    It does say that if comparisons are being made then... and comparisons are being made, so yes, it does.
    - int_19h 5y ago
      If comparisons are being made of Unicode strings, sure. Does the protocol actually defines the identifier in question as a Unicode string, though? Or as an array of 16-bit ints?