Mule bugs: misidentification (Latin-1 vs. Chinese), revert issues

[Stephen J. Turnbull]

Aidan Kehoe writes:

 > On your original question; it's laughably unlikely (outside of
 > Cygwin, where this code is not used) that ls will output file names
 > in a coding system that doesn't reflect the octets stored in the
 > directory entries.

Well, no, it's not funny at all in Japan where I know of servers
running in EUC or UTF-8 but handle Shift-JIS stores.  I wouldn't be
surprised if similar issues arise with respect to KOI-8 and Big5.

 > And on OS X
 > file-name-coding-system (and relatedly, the 'file-name coding system alias)
 > is unconditionally UTF-8, independent of the locale coding system.

This is a good heuristic, since the most popular file system on OS X
is HFS+, which does try to enforce UTF-8 file names.

 > I would suggest binding coding-system-for-read to 'file-name, not
 > (get-coding-system-from-locale (current-locale)) .

Yes, that's an excellent idea; it give the user enough control to deal
with the unusual cases described above.