The good news is that I have a fix. The bad news is that it comes in the form of a commercial NFS client, called ProNFS, which costs US$40. That’s at least $15 more than I feel entirely comfortable paying, but there’s a 30-day trialware edition that at least you can test stuff out with before you part with your hard-earned moolah.

Crucially, in the client settings tool that is provided as part of the ProNFS software stack, there’s this little dialog box:

Spot the reference to using UTF8 file names! Woot!

Once you then use the ‘map drive’ tool to find your NFS shares and mount them as a standard windows drive letter affair, everything works as advertised on the tin-lid:

Spot all those European names displaying correctly, replete with accents, umlauts and cedillas! Problem solved, I think.

I do have a few “issues” with this approach to solving the problem, though. I suppose the first one is simply this: “if they can do it, why can’t you, Microsoft?!”. The second is that the installer for this program looks like it was written in 1994 and hasn’t been updated since! There are lots of little touches on the company’s website, for example, that make me nervous -constant references to the software being compatible with Vista, for example, with never a mention of Windows 7. If you check out their promotional screenshot, too, it will seem as if the software hasn’t been updated since 2003! They’re shooting themselves in the foot there, because if you actually run the NFS server component today, it will report version 1.6 with a compile date of June 23rd 2011, which is much more reassuring! Finally, there’s the not-so-minor matter of the Blue Screen of Death I got when I removed the evaluation version and performed post-removal reboot. I haven’t seen one of those for years, so getting one as the software is removed didn’t fill me with warm glows and kindly feelings!

In the end, though, such things are probably not major issues. I should say in fairness that once the software was installed and running, it behaved itself perfectly -and I can live with slightly out-of-date documentation and promotional wares so long as the software behaves itself. Yes, I could wish it were a tad cheaper, but even at US$40, if it means I don’t have to configure Samba, it’s probably just about worth it! Colour me happy, ish.

The obvious answer is ‘Samba’: a quick fiddle on the file server to install the requisite Samba server packages, a modest amount of editing smb.conf and (usually) all is set and ready to run.

This time, however, I thought I’d be a bit more adventurous. Every other Server, PC, laptop or netbook is running Linux, so why impose the overhead of Samba if it’s not needed for most of the machines on my network? Why not get Linux’s “native” file sharing system (NFS, or Network File System) running instead and get the Windows PC hooking into that?

Well, the NFS bit is indeed incredibly easy to set up. It’s already installed on the server: all I had to do was make sure the firewall allowed traffic through (on ports 111 and 2049), configure an export file and start the relevant service. All done in about 5 minutes, to be honest -which is a lot faster than Samba usually is for me! The export file (/etc/exports) couldn’t be much simpler, either, for it contains just one line:

/safedata 192.168.0.0/24(rw,sync)

The safedata directory is the mount point for my RAID 5 array, so has all the important data on it. I’m just saying here that anyone on my home network is allowed to get read-write access to it (in principle, anyway… normal file permissions still apply, so unless I’ve chmodded everything 777, not everything will be writeable).

The Linux clients are a doddle to configure, too: it’s simply a matter of typing this sort of thing (as root):

mount 192.168.0.100:/safedata /nfsmounts

That just says ‘find the “safedata” export on the file server and mount it at the /nfsmounts mount point’. And, just as I had hoped, I found large files could be copied across to the server from my desktop at a rate of about 48MB/sec. That’s 384 megabits per second, which isn’t bad for my rather humdrum gigabit Ethernet link -and a lot faster than the consistent 25MB/sec I used to get on exactly the same hardware when using Samba to do Linux-to-Linux transfers.

So NFS it is, then!

Not so fast! There’s the not-so-minor matter of configuring The Other Half’s Windows PC to partake in this feast of NFS-ness. As I mentioned, that’s running Windows 7… and it’s the Ultimate edition, which means an NFS client is readily available. All you have to do is go to Start > Control Panel > Programs and then select the Turn Windows features on or off option:

You simply find the Services for NFS item, expand it and select the two sub-options for activation. Once you’ve done that, you can then issue ‘mount’ commands on Windows that resemble their Linux cousins very closely:

The basic format of the command is simply mount server:/share/name drive_letter: …and in my case, it means my Music folder stored on the server’s RAID array is now accessible from the Windows PC by navigating to the M: drive in Explorer:

And this is the point where the good news abruptly ends. Sure, getting the NFS export seen and mounted by the Windows PC is a piece of cake… but as any fule kno, André Mathieu’s name is spelled with an ‘e-acute’ at the end of his first name, not a capital-A-plus-Copyright-symbol as Windows Explorer seems to think is appropriate. Arnold Schönberg will also be missing his O-umlaut and wouldn’t be impressed with his newly-acquired A-with-tilde-plus-paragraph-mark.

Of course, what we have here is ye olde and ancient trouble with extended Western European ‘foreign’ characters. It’s bugged me for years when doing Samba mounts (but is easily fixed there by specifying a utf-8 mount option when issuing the mount command). Now it’s back with a vengeance… and there’s nothing I can do (apparently) to fix it!

Here’s the real problem, from the Windows perspective:

The mount command on its own lists network drives which have been mounted and the options/attributes that apply to those mounts. The killer line here is lang=ANSI, indicating that Windows has mounted the network drive assuming that it will find only ANSI characters at the other end. When it then actually finds UTF-8 characters instead, it gets itself very confused, as we’ve seen.

Knowing this, it’s easy to speculate that there must be a way of specifying something like lang=utf8 when performing the original mount command and that this would fix the problem:

That’s me first unmounting the M: drive I’d created before and then attempting to re-mount it but with a utf8 language specified instead of the default ansi one. As you can see, however, “utf8″ is not an option that’s actually available for this parameter. You can certainly choose a variety of Chinese, Korean and Japanese character sets -and, of course, “ansi” is valid, but not “utf-8″ or anything like it.

As far as I could tell from reading the documentation that comes with the Windows 7 NFS client (go to Control Panel > System and Security > Administrative Tools then open the Services for Network File System (NFS) program and hit [F1]), there are no other mount options that can be specified which would have anything to do with getting the character set right. So, as best as I can tell, there is no fix for this problem… which is truly dumb!

Just to emphasize how silly this is, here’s the exact same Windows PC browsing through the exact same folders on the exact same server …only this time, using Samba:

The two Andrés have their acute accents, and Arnold gets his umlaut back… no problems at all.

For me, unless someone else points me in the direction of a fix, this simply means it’s back to Samba and boo-hiss to NFS, which is a shame as I would much prefer things the other way round.

There are, apparently, commercial NFS clients for Windows. I may have to try to evaluate one of those to see if the character set issues are surmountable, but I am not holding my breath. In the meantime, the freebie stuff from Microsoft on this score is functionally useless to me