[Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

[John Millikin]

Both packages now have much-improved support for non-UTF8 paths on
POSIX systems. There are no significant changes to Windows support in
this release.

system-filepath 0.4.5:
Hackage: http://hackage.haskell.org/package/system-filepath-0.4.5
API reference: https://john-millikin.com/software/haskell-filesystem/reference/system-filepath/0.4.5/

system-fileio 0.3.4:
Hackage: http://hackage.haskell.org/package/system-fileio-0.3.4
API reference: https://john-millikin.com/software/haskell-filesystem/reference/system-fileio/0.3.4/Filesystem/

-----

In GHC  7.2 and later, file path handling in the platform libraries
was changed to treat all paths as text (encoded according to locale).
This does not work well on POSIX systems, because POSIX paths are byte
sequences. There is no guarantee that any particular path will be
valid in the user's locale encoding.

system-filepath and system-fileio were modified to partially support
this new behavior, but because the underlying libraries were unable to
represent certain paths, they were still "broken" when built with GHC
7.2+. The changes in this release mean that they are now fully
compatible (to the best of my knowledge) with GHC 7.2 and 7.4.

Important changes:

* system-filepath has been converted from GHC's escaping rules to its
own, more compatible rules. This lets it support file paths that
cannot be represented in GHC 7.2's escape format.

* The POSIX layer of system-fileio has been completely rewritten to
use the FFI, rather than System.Directory. This allows it to work with
arbitrary POSIX paths, including those that GHC itself cannot handle.
The Windows layer still uses System.Directory, since it seems to work
properly.

* The POSIX implementation of createTree will no longer recurse into
directory symlinks that it does not have permission to remove. This is
a change in behavior from the directory package's implementation. See
http://www.haskell.org/pipermail/haskell-cafe/2012-January/098911.html
for details and the reasoning behind the change. Since Windows does
not support symlinks, I have not modified the Windows implementation
(which uses removeDirectoryRecursive).