This isn't how two factor authentication is supposed to work

Dear Apple,

I feel so much more secure now that I have two factor authentication enabled.

End Sarcasm.

For those who don't get it,
it's sending the passcode to the actual device that is attempting access

Error -50 when trying to write to an HFS+ Journaled file system

First, credit where credit is due.  The answer came from https://discussions.apple.com/

One of my Seagate drives suddenly started acting really weird.  It wouldn't let me delete files from it, copy new files on to it, etc.  Copying files off the drive seemed to work fine, but when I tried to run Disk Utility to validate the file system, it gave an error complaining about being unable to dismount the file system - someone had it busy.

Quick trip to the Terminal and tried:

$ sudo lsof | grep VOLUMENAME

and that showed a couple of issues, OneDrive, GoogleDrive, etc keeping files open, so I quit those apps and tried again.  Same dismount problem, even though there were no open files that the system would tell me about.   Hmmm, real Unix fsck can run on a mounted filesystem, surely the hfs variant can?  Yep.  First, work out the device name with mount ...

$ mount

/dev/disk0s2 on / (hfs, local, journaled)

devfs on /dev (devfs, local, nobrowse)

map auto_home on /home (autofs, automounted, nobrowse)

/dev/disk2s2 on /Volumes/VOLUMENAME (hfs, local, journaled)

... then run the HFS checker using that device name

$ sudo fsck_hfs -ld /dev/disk2s2

... and that claimed that the file system was fine.

Back to Google, found the thread at discussions.apple.com which suggested that the problem might be a corrupted journal.  His solution was more complicated than I needed because I don't have a hardware failure to contend with, so I tried doing it online.

Turn off journaling with Apple's hidden hfs.util tool:

$ sudo /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util \

    -N /Volumes/VOLUMENAME

and try Disk Utility again.  Lo and behold, now it can unmount.  Let it run through the check and it gives the drive the thumbs up.  Turn journaling back on:

$ sudo /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util \

    -J /Volumes/VOLUMENAME/

Allocated 229376K for journal file.

And we are back in business.  No idea why the journal went bad, and I'll make sure my backups of all the stuff on that drive are up to date. 

P.S. The crappy fonts and colouring in this post are a function of this wysiwyg editor that blogger.com provides.

P.P.S Less than two weeks later, the same disk has died again but this time with an error that fsck does not seem to be able to fix.  Sigh.

mDNSResponder running rampant

So, this morning I took at look at my Mac and noticed that Little Snitch shows that someone is doing almost constant network traffic out.  Looking in the Network Monitor, it appears that mDNSResponder is sending almost constantly to our DNS server.

Useful tip 1:  To debug what mDNSResponder is doing, use the following:

sudo killall -SIGUSR1 mDNSResponder

and then take a look in the Console log.  This is a toggle so do the same command to disable the extended logging.  (Thanks to http://krypted.com/mac-os-x/mdnsresponder-mdns-and-dns-sd/ - I could have just read the man page (man mDNSResponder) but who has time to read local documents when you have Google?)

Some internet pages suggest you can get this symptom if you have a misconfigured DNS server that does not report errors correctly. This does not appear to be the problem for my ISP (Optus).

In my case, the log showed messages like this:


26/01/13 9:55:50.819 AM mDNSResponder[40]:  24: DNSServiceQueryRecord(35000, 0, 1.0.0.127.in-addr.arpa., PTR) START PID[264](LogMeInGUI)
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: Error socket 72 closed  00000000 00001005 (0)
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: Error socket 72 created 00000000 00001006
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: DNSServiceQueryRecord(35000, 0, 1.0.0.127.in-addr.arpa., PTR) START PID[264](LogMeInGUI)
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: Error socket 72 closed  00000000 00001006 (0)

Hmmm, LogMeIn?  Don't I have that switched off?

I checked the LogMeIn control application and yes, it definitely shows as "Off" - that's the normal state for me.  On a hunch, I turned it "On" and immediately the mDNSResponder traffic ceased.  Turn if "Off" and mDNSResponder again starts sending.

So, LogMeIn, when turned off, generates more network traffic than when it is turned on and idle.

I've reported it to LogMeIn.com - we'll see what happens.  For now, I'll probably uninstall.

Samba NAS and error code -36

I just bought a Seagate GoFlex Home NAS and was wanting to backup a bunch of files to it. I ran their installer, installed all their recommended tools, configured the server, and got a Folder on my desktop representing the "GoFlex Home Public" folder on the server.

The first thing I tried to backup was their installation software, and I got this:

The Finder can’t complete the operation because some data in “some folder” can’t be read or written.

(Error code -36)

It's taken me several hours and lots of unsuccessful internet trawling to finally work out what the workaround is, so I figure its worth a post here where Google can find it for the next guy.

The problem appears to be related to the use of extended attributes, which Snow Leopard loves to attach to files these days. I believe that there is some sort of problem writing files with the com.apple.quarantine attribute to Samba mounted disks. Whilst you can try to use xattr -d to remove those attributes from your files, its tedious and very error prone.

Similarly, I found that sometimes files got stuck on the drive - you couldn't remove them, if you tried (in the terminal) you'd get permission errors. Nothing, sudo included, would allow you to fix the permissions. Yet looking in a terminal window with /bin/ls, they looked fine.

Short answer: Don't use the GoFlex Home Agent to mount network folders.

This always uses the smb: protocol to access the server. Instead, use the "Connect to server..." command on the "Go" menu in the finder, and explicitly specify that you want to use the afp: protocol instead.

Once I switched to using afp:, all of the spurious errors went away. I was able to delete all the temporarily stuck files, and I could copy whatever I liked onto the drive, regardless of the extra attributes.

Strangely enough, when I then tried out the Memeo Backup that Seagate include in the package, it warned me that my backup volume is afp: and I should use smb: instead. Yeah right. However, it looks like one reason they recommend smb: is that the afp: volume didn't seem to auto-mount when I went back in - I had to mount it for them.

Update:

Alternately, you can just wait for Apple to release OSX 10.6.7 which "resolves an issue when transferring files to certain SMB servers". Clearly, this blog post blowing the whole issue wide open had them scared and they realised they had to fix it pronto, or face my scathing posts.

Update 2:

Hmmm, despite it "mostly" working, I keep getting errors from Time Machine saying it was unable to complete the backup - it looks to me like it fails if it has to mount the drive itself.

Moral: do not buy this drive if you want to use it for Time Machine backups.

PDF to JPEG conversion

Various PDFs collected from around the net would be better off as individual image files. You'd think there'd be a standard tool to convert them but I couldn't find any at a price point I was interested in. Fortunate OSX Python has access to CoreGraphics which can do the heavy lifting.

#!/usr/bin/python
import sys,re,os,os.path
from CoreGraphics import *

def doit(pdfname):
  if not re.search(".pdf$",pdfname): return
  print pdfname
  dirname = re.sub(".pdf$","",pdfname)
  try:
     os.mkdir(dirname)
  except:
     print "Can't create directory '%s'"%(dirname)
     return

  pdf = CGPDFDocumentCreateWithProvider(CGDataProviderCreateWithFilename(pdfname))
  cs = CGColorSpaceCreateDeviceRGB()
  bg = CGFloatArray(5)       # create's an array of 5 0's which is good enough for me
  for i in range(1, pdf.getNumberOfPages() + 1):
     page = pdf.getPage(i)
     r = page.getBoxRect(kCGPDFMediaBox)
     h = r.getHeight()
     w = r.getWidth()
     del page

     #c = CGBitmapContextCreateWithColor(int(w), int(h), cs, (0,0,0,0))
     c = CGBitmapContextCreateWithColor(int(w), int(h), cs, bg)
     c.saveGState()
     c.setInterpolationQuality(kCGInterpolationHigh)
     c.drawPDFDocument(r,pdf,i)
     c.restoreGState()
     c.writeToFile(os.path.join(dirname, "page%04d.jpg"%i),kCGImageFormatJPEG)
     del c
  del cs
  del pdf

if __name__=='__main__':
  for a in sys.argv[1:]: doit(a)

The original version of this script was broken by Snow Leopard (which upgraded Python to 2.6.1). The call to CGBitmapContextCreateWithColor() failed with an error message about the 4th argument which it seems to think shouldn't be a 'const float[5]'.
The solution is to pass in a CGFloatArray() object instead. I haven't been able to modify one of those, but the default thats produced when you use 'bg = CGFloatArray(5)' appears to be good enough. Those objects still look leaky as hell but what are ya gonna do?

Squirrel:~ jeff$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from CoreGraphics import CGFloatArray
>>> a = CGFloatArray(5)
>>> print repr(a)
<CoreGraphics.CGFloatArray; proxy of <Swig Object of type 'CGFloatArray *' at 0x2287a0> >
>>> print repr(a[0])
swig/python detected a memory leak of type 'CGFloat *', no destructor found.
<Swig Object of type 'CGFloat *' at 0x224d10>
>>>