For personal use, the UBitMenu is free.

It’s a tiny install that creates a “Menu” tab in the Office ribbon -inside of which sit all the old-fashioned menus whose location and functions you probably know intimately, having used Office for 15+ years. Instead of poking around the “improved” ribbon for hours at a time wondering where the hell everything is hiding, now you can use Office as you once knew how to, all over again!

I’ve spent 4 years trying to get familiar with the Ribbon. I cheerfully admit that this is a lot more useful for me!

Unfortunately, when I then tried to do anything with the files produced by the extraction process, all failed to work: music and video files simply refused to play in VLC, Movie Player or anything else, for example.

I feared the worst: a corrupt zip file. I was about to shrug my shoulders, delete the zip file and chalk it up to experience when I thought, ‘let’s try to repair the zip!’ Nothing ventured, nothing gained after all… and if the repairs failed to work, I’d at least be no worse off than I was already.

Two programs suggested themselves, thanks to Google (both Windows-only, so run in a virtual machine).

First up: Disk Internals. Small download, apparently free, nice wizard point-and-click interface. A bit slow identifying anything capable of being recovered… and, in the end, it only output a couple of hundred files (out of over 3800 in the original zip) before falling over in a heap and crashing. None of them was usable.

So, second try: Object Fix Zip. Another small download, standard Windows installation and simple wizard interface. On its first run, it prompted me for a password to the zip file… and it was at that point I suddenly remembered that I had, indeed, password-protected the original zip file. I also suddenly realised that the Disk Internals program had never prompted me for a password… no wonder that first program had been unable to recover anything usable!

Even more interesting, Object Fix Zip prompted me for a password… and then kept prompting me for each file it encountered within the zip. It would accept the password I typed, extract a file from the zip, move onto the next file within the zip and then prompt me again. Then I noticed that (a) every file it appeared to extract was unusable and (b) I could type a password I knew to be rubbish… and the program would continue to extract, move on, re-prompt.

That in turn made me realise something: the Linux Extract Here menu option had never prompted me for a password at all… and its outputs were useless. The Disk Internals repair tool had not prompted me for a password either… its outputs were similarly useless. Object Fix was at least prompting me for a password … but its continual prompts regardless of what I typed in seemed to suggest that maybe I was providing an incorrect password all along.

So then the penny dropped: could the original idea that my zip file was corrupt be merely the result of the non-supply of a password, or the supply of a wrong password?

I re-ran Object Fix a couple of times more, each time supplying a different plausible password. And Lo! On one of these subsequent runs, it accepted the password and stopped asking for it after that. Clearly, when the right password was supplied, it only needed to be told it once. And, even better, the files being output by the Object Fix tool were (drum roll, please)… completely usable.

To cut a long story short, I then went back to my Linux desktop and used the Linux equivalent of 7zip (called p7zip, but invoked with the command 7za) to extract the file:

7za x /path/filename.zipghjghjgh

…and this program properly prompted me to supply a password. When I typed in a password I knew couldn’t possibly be correct, the program at least told me there was a problem:

CRC Failed in encrypted file. Wrong password?

The second part of that message is, at least, a good, strong clue as to what’s wrong, although you could get the wrong idea entirely if you paid any attention to that bit about CRC  failing. A genuinely corrupt file would generate warnings about CRC failures, after all!

So, finally, I re-ran 7za with what I knew by this time to be the correct password… and the whole thing extracted itself without a hitch. All files were usable, all 78GB of data were back safely from the brink!

In summary, if you think your zip file is corrupt, make sure it wasn’t originally password-protected. If it was password-protected, don’t expect Linux’s ‘extract here’ functionality to prompt you for the password -and expect its output to be garbage as a result. A program like p7zip will prompt you for a password appropriately, but may not be obvious about it if the password you supply turns out to be incorrect. And don’t give up on your zip until you’ve exhausted every conceivable password!

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

There are two essential problems.

The first is that I run Windows 7 64-bit and LibreOffice only comes as a 32-bit Windows download. This means, in turn, that a 64-bit Java Runtime Environment is not recognised by LibreOffice, which therefore complains that no JRE exists whenever you try to connect to a database with its “Base” application. The fix here is to install a 32-bit JRE, which you can do by going here and making sure to select the Windows 7/XP Office (32-bit) download. 32-bit and 64-bit JREs can co-exist on the same PC, so installing both is not an issue.

The second is that Base connects to Oracle via its ‘Oracle JDBC’ option, which is there from the get-go… but which won’t work because it doesn’t know how to load the necessary Java classes. The fix here is to make sure you know where your ojdbc6.jar file is (which contains the necessary classes): on my Windows laptop on which I’d previously installed a complete 11g Release 2 database, that file can be found in %ORACLE_HOME%jdbclib (which, in my case, is c:apphjrproduct11.2.0dbhome_1jdbclib). With that location in mind, you need to open any of the LibreOffice applications, go to Tools > Options > Java and click the Class Path button. Click the Add Archive button and navigate to the …jdbclib directory and point it at the ojdbc6.jar file. Click OK as appropriate to store the new setting.

At which point, you should be good to go.

If, as is quite likely, you don’t have a complete Oracle installation on your client PC, and you’re disinclined to install a big, fat client either, then you can simply download the necessary ojdbc file from Oracle and stick it somewhere convenient. Point your LibreOffice Java Class Path at it, wherever it might be, and you should be good to go. For example, this shows you I have no Oracle client or database installed on this particular PC:

…you’d see something like ‘Oracle – OraDB11g_home1′ in the menu if I’d installed an Oracle database or client. But I did download the ojdbc6 file to my desktop -and here’s the LibreOffice setting for that:

And having set that, it’s then trivial to point LibreOffice’s Base at my Oracle database:

After which, standard ‘Access-like’ stuff becomes possible. Here’s LibreOffice’s Base and the good ol’ EMP table:

In short, it’s all relatively painless -provided you to stick to a 32-bit client/JRE and you know how to point your LibreOffice installation to your ojdbc class library.