You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
addWatch can crash if fed a filename that contains a character that is not valid in the current locale. For exampe, in the C locale, the ü character is not valid.
This is due to the complex way that GHC handles invalid characters in filenames. It uses a FileSystemEncoding which represents those characters using special high unicode surrigate characters. Filenames that are read in (eg by getDirectoryContents) have this encoding applied. Filenames that are passed to C code have this encoding reversed, to get back to the original byte string that matches the file on disk. GHC has been doing this for a year or two (7.6 iirc).
addWatch does not apply the FileSystemEncoding when calling C code. Note that since addWatch first calls getFileStatus on the filename, the caller cannot just arrange for the encoding to be applied before calling addWatch.
I have a patch, which I'll send in a pull request. This is affecting multiple users, so I hope it can get fixed quickly.
The text was updated successfully, but these errors were encountered:
addWatch can crash if fed a filename that contains a character that is not valid in the current locale. For exampe, in the C locale, the ü character is not valid.
This is due to the complex way that GHC handles invalid characters in filenames. It uses a FileSystemEncoding which represents those characters using special high unicode surrigate characters. Filenames that are read in (eg by getDirectoryContents) have this encoding applied. Filenames that are passed to C code have this encoding reversed, to get back to the original byte string that matches the file on disk. GHC has been doing this for a year or two (7.6 iirc).
addWatch does not apply the FileSystemEncoding when calling C code. Note that since addWatch first calls getFileStatus on the filename, the caller cannot just arrange for the encoding to be applied before calling addWatch.
I have a patch, which I'll send in a pull request. This is affecting multiple users, so I hope it can get fixed quickly.
The text was updated successfully, but these errors were encountered: