Logged In: YES 
user_id=21627

I disagree with the last assertion: In *particular* if the
file system encoding is UTF-8, there is a good chance that
decoding will fail (unlike if it is latin-1; decoding will
then never fail - it may just produce mojibake). 

OS X seems to make a guarantee to always return UTF-8 from
its low-level API, but I distrust this guarantee until I see
it with my own eyes :-) E.g. what happens if you mount an
NFS tree, and the NFS server gives file names in some other
encoding?

I see the following options:

- only enable the code for OS X. I dislike this option, as
it essentially freezes the Unix status to non-Unicode (we
won't get further insights, the de jure status won't change,
de facto, all files will be encoded in the locale's encoding).

- leave the code as-is, documenting the possibility of
exceptions.

- add byte strings instead of Unicode strings into the
result for non-decodable strings. This gives a mixed-type
result, which is fine if you only pass the resulting file
names to stat() or open(), and will likely break the
application if it tries to display the file names somehow.