fileio tests fail on OS X, perhaps due to error in temporary?

[tel]

I'm not sure where the appropriate place to raise this issue is, but it appears that tests are failing due to the nonexistence of desired temporary files.

[nix-shell:~/tmp/qewr/system-fileio-0.3.16]$ cabal test
Preprocessing library system-fileio-0.3.16...
In-place registering system-fileio-0.3.16...
Preprocessing test suite 'filesystem_tests' for system-fileio-0.3.16...
Running 1 test suites...
Test suite filesystem_tests: RUNNING...
[ ABORT ] posix.copyFile.iso8859
  Test aborted due to exception: /var/folders/lj/655x29_s66718hvw6bdcvy1w0000gn/T/tests.iso8859.23369/old_¡¢£.txt: openBinaryFile: does not exist (No such file or directory)

[ ABORT ] posix.withFile.read.iso8859
  Test aborted due to exception: /var/folders/lj/655x29_s66718hvw6bdcvy1w0000gn/T/tests.read.iso8859.23369/¡¢£.txt: openBinaryFile: does not exist (No such file or directory)

[ ABORT ] posix.withTextFile.iso8859
  Test aborted due to exception: /var/folders/lj/655x29_s66718hvw6bdcvy1w0000gn/T/tests.iso8859.23369/¡¢£.txt: openFile: does not exist (No such file or directory)

FAIL: 81 tests run, 66 tests passed, 12 tests skipped, 3 tests aborted
Test suite filesystem_tests: FAIL
Test suite logged to: dist/test/system-fileio-0.3.16-filesystem_tests.log
0 of 1 test suites (0 of 1 test cases) passed.

[chrisdone]

Perhaps the unicode is problematic? Don't have OS X running to confirm.

[tel]

Could be. Would that error be in temporary then?

[jml]

It's not temporary.

I picked one of the tests and tried to make a minimal executable that demonstrates the problem. You can see it here: https://gist.github.com/jml/c832355ff1642fba8af9

touch_ffi creates a file called old_%A1%A2%A3.txt. copyFile then tries to open old_¡¢£.txt, which does not exist.

Text encoding always makes my head spin, but my best guess is that since HFS+ stores paths as UTF8-encoded strings, that it doesn't make sense to even test iso8859 for that filesystem.

(some Googling later) It appears that this code base already knows that, since Filesystem.Path.Rules.darwin exists.

Because of the different types, it's not easy to just encode those examples with the darwin rules when on that platform.

Two suggested fixes:

1. Make a clone of Posix.hs for testing darwin, making the necessary changes
2. Just disable these three cases if running on darwin

See also:

• Official Apple article on Text encodings in virtual filesystems
• comment in Python tests which cites that article
• "POSIX API calls on MacOS X both expect and return file names that are UTF-8 encoded" from some forum somewhere

[jml]

Oh hey, there are already cases where you do 2. in the test suite. Patch on its way.