behaviour change in getDirectoryContents in GHC 7.2?

[John Millikin]

You're right -- many parts of system-fileio (the parts based on
"directory") are broken due to this. I'll need to update it to call
the posix/win32 functions directly.

IMO, the GHC behavior in <=7.0 is ugly, but the behavior in 7.2 is
fundamentally wrong.

Different OSes have different definitions of a "file path". A Windows
path is a sequence of Unicode characters. A Linux/BSD path is a
sequence of bytes. I'm not certain what OSX does, but I believe it
uses bytes also.

In GHC <= 7.0, the String type was used for both sorts of paths, with
interpretation of the contents being OS-dependent. This sort of works,
because it's possible to represent both byte- and text-based paths in
String.

GHC 7.2 assumes Linux/BSD paths are text, which 1) silently breaks all
existing code and 2) makes it impossible to fix within the given API.

On Tue, Nov 1, 2011 at 08:48, Felipe Almeida Lessa
<felipe.lessa at gmail.com> wrote:
> On Tue, Nov 1, 2011 at 5:16 AM, Ganesh Sittampalam <ganesh at earth.li> wrote:
>> I'm just investigating what we can do about a problem with darcs'
>> handling of non-ASCII filenames on GHC 7.2.
>>
>> The issue is apparently that as of GHC 7.2, getDirectoryContents now
>> tries to decode filenames in the current locale, rather than converting
>> a stream of bytes into characters: http://bugs.darcs.net/issue2095
>>
>> I found an old thread on the subject:
>> http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html and
>> some GHC tickets (e.g. http://hackage.haskell.org/trac/ghc/ticket/3300)
>>
>> Can anyone point me at the rationale and details of the change and/or
>> suggest workarounds?
>
> You could try using system-fileio [1], but by reading its source code
> I guess that it may have the same bug (since it tries to decode what
> the directory package gives).  I'm CCing John Millikin, its
> maintainer.
>
> Cheers,
>
> [1] http://hackage.haskell.org/packages/archive/system-fileio/0.3.2.1/doc/html/Filesystem.html#v:listDirectory
>
> --
> Felipe.
>