The university is in the process of upgrading staff email servers from Exchange 2007 to Exchange 2010, and then onwards to 2013 thereafter. This is a positive move for non-Windows users as the more recent versions of Exchange have much better support for web browsers other than Internet Explorer, and also seem to fix issues such as the ‘mail attachments not showing in Apple Mail’ bug. However, as with any update there are issues. This one I found out about a few months ago while assisting a colleague in Medicine who had an account at their former institute, where they ran Exchange 2010.

The problem, as first reported to me, was “every file has the spaces in the filename replaced with % signs” which was indeed puzzling. On closer inspection it turned out that the problem did not affect every file, just those coming from the Exchange 2010 webmail client, and that the spaces were being replaced with %20. At this point I realised what was happening.

To explain this we need to step back a moment. Once upon a time filenames were typically something.txt or image.jpg – very simple and with no fancy characters. Then deviant Mac and Unix users started using other characters in their filenames, and soon Windows followed suit (hello Windows 95). This is fine in most cases, but gives a problem for web browsers which don’t deal well with spaces in URLs. For example, this won’t work:

http://www.example.com/documents/My Lovely Horse.mp3

as the browser will ask for the file ‘My’ instead of ‘My Lovely Horse.mp3’

Rather than have people rename all their files, web servers use percent codes to encode these characters. The % symbol is used to denote the start of an escape sequence, and is followed by the ASCII or Unicode number of the escaped character. In this case, space is ASCII character 20, so the URL above becomes

http://www.example.com/documents/My%20Lovely%20Horse.mp3

which is less readable for humans, but much better for computers.

Getting back to the point, when someone sends an email with an attachment whose filename contains spaces, the Exchange webmail client will present this file with the filename percent encoded. If you try to download the file via webmail then things get ‘interesting’. Some browsers, such as Safari, will literally save the attachment with the exact name presented, %20 and all. Others, like IE, Firefox, and Chrome, will convert the percent encoded characters to their normal equivalents. Which is the ‘right’ thing to do is a matter of opinion, but the latter is clearly more convenient for users!

If you’re struck with this issue you have a few choices:

1. Don’t use webmail
2. Don’t use Safari
3. Use Automator to create a droplet which does the necessary renaming

In most cases option 2 is the better one, with Chrome being my alternate browser of choice since Firefox currently chokes on QOL authentication. Option 3 is not that difficult but beyond the scope of this blog post!

I did some Googling around this problem and saw there were other possible solutions involving server-side configuration and hacking about with Safari extensions, but those all seemed too much effort for either server admins or users!

It’s a little known fact (amongst normal people) that encryption algorithms are considered to be munitions in law. Thus those little equations are governed by the same laws as exports of fighter jets, etc. Why should you care? Well, if you use a laptop for QUB work, you should be encrypting its storage to protect any sensitive content on it – and given that ‘sensitive’ is a loose term it’s best to encrypt under all circumstances. If, however, you go travelling then suddenly you have a dangerous item under your control.

While most jurisdictions permit the personal use of encryption, some forbid it without explicit permission. While unlikely, it’s possible that a border guard could insist on the machine being decrypted, and it could be seized. Thus the sensible approach is to *not* bring your laptop to one of these countries, but to bring a spare system which is unencrypted but contains nothing but the bare essentials for your trip.

The university is not aware of any staff being affected by this as yet, but it is best to be aware of the possibilities. I had a conversation about this last week with senior folks in IS.

You can find a list of the “difficult” destinations at http://www.cryptolaw.org/cls-sum.htm

The destinations which some of you may go to, which do require care, are:

• China – a permit issued by the Beijing Office of State Encryption Administrative Bureau is required.
• Hungary – an International Import Certificate is required.
• Israel – a license from the Director-General of the Ministry of Defense is required.
• Russia – licenses issued by both the Federal Security Service and the Ministry of Economic Development and Trade are required. License applications should be submitted by an entity officially registered in Russia.
• Saudi Arabia  – it has been reported that the use of encryption is generally banned, but inconsistent information exists.
• Ukraine – a license issued by the Department of Special Telecommunication Systems and Protection of Information of the Security Service of Ukraine (SBU) is required.

Especially in the case of Russia and China, given the known risks of state-sponsored (highly competent) hacking, it would be prudent to adopt maximum paranoia, use a loaner laptop which is erased on return, and change all passwords. Indeed, one might well set up a ‘burner’ email address to use for the trip, and not touch normal accounts in the meantime.

As Snowden has shown, you can’t be too paranoid these days.

I know I should update this blog more often, but I keep having to deal with problems which are blog worthy. There’s an irony. I have a lovely post coming up about problems with Mail.app and adding CRLFs to text files, for example. That episode is enough to have me looking at using Outlook for work email.

Anyway, this post is about the importance of backups. Plural. One backup is never enough, as I was reminded yesterday.

Our MSci iMacs are backed up to a QNAP NAS which offers Time Machine compatibility. The only officially supported network Time Machine clients are either Apple’s Time Capsule or else storage served up by OS X Server. Neither work well for us – Time Capsule is a home technology, and I’ve had enough problems with OS X Server (post Snow Leopard) that the proverbial wild horses would not get me back to using it again. I wanted to use networked Time Machine as we had a small issue with roof leaks which meant that machines and their USB-attached backup drives were getting soaked (fair play to Apple, one iMac has been rained on twice and still works fine), and the QNAP seemed like a reasonable choice.

On a local USB disk Time Machine works by copying files direct to the drive; simple and efficient. On a network disk, no matter the source, it creates what’s called a sparse bundle disk image. This is a directory which emulates a single file, sort of like an ISO CD image. The directory contains multiple smaller files, called bands, which sort-of correspond to sectors on the virtual drive. These are 8MB each, and the idea is that only sectors which are needed are created. The problem with this approach is that for large disk images, say around the TB level, you’re looking at maybe 120,000 of them, which might be a lot of overhead for the server to deal with.

A machine had a hard drive failure, so I brought up the spare and started to restore files from the Time Machine backup using Migration Assistant. All went OK apart from a 500GB directory, which would only copy at around 1-200 kB/s, and that on a gigabit LAN capable of up to 100MB/s. I tried many different options to get at the data and no matter what I did the machine was intolerably slow, and crashed entirely twice. At this point I was most unhappy, and found myself wishing for a second backup (which I had said we’d needed and been overruled on).

In the end, I managed to get the data off the machine by turning off all Apple file sharing, mounting the TimeMachine partition via NFS on my iMac, opening the disk image and copying the files out from there. That worked OK, giving me the expected 50MB/s transfers. So clearly the disk image was OK, it’s just that the QNAP could not serve it efficiently over the AFP protocol.

Lessons from this? Firstly, always have more than one backup. I’ve already ordered some USB hard drives and set up an rsync script to a remote server as a stopgap to a better networked solution. Secondly, I don’t think that networked Time Machine is a good idea, however it’s done. On my home network I’ve had issues with disk images getting corrupted on my Time Capsule, or just failing without an error, and that’s with 100% Apple kit. Relying on an unapproved third-party work-alike for important things is not worth the risk. In the future I think I’ll be using locally attached hard drives for Time Machine, and some other network arrangements for disaster recovery – either rsync or Chronosync are top of my list. Along with some proper ‘enterprise’ grade storage…

Now, back to playing with Outlook. Sigh.

I sort of forgot I should be updating this thing. Whoopsie.

It appears that Snow Leopard is officially dead to Apple now. Not that there is anything like an official statement of course.

In the continued absence of updates for Mountain Lion, as mentioned previously, it’s hard to avoid the feeling that Apple is pushing us to Mavericks, like it or not.

I’m running Mavericks on my main machines now, and it seems OK, though my own needs are quite mainstream. Anyone depending on third party software which is not yet ported to Mavericks or which requires paid upgrades is in a bit of a bind.

Bad Apple.