Burn CDs without the invisible .DS_Store (dot) files

This has been bugging me for years. I think I've finally figured it out.

The interesting bit, really, is why this problem is so mysterious. In think the mystery comes about because only old-timers wonder about this, for most people I suspect things just work (on CD anyway).

Long time OS X users remember when CDs were littered with .DS_Store and other OS X "dot" files holding file metadata. Some versions of OS X create these even when there's no extended attributes, resource fork, or other metadata for a particular file.

It's not just CDs. Thumb drives (USB mass storage media) got them too.

They're annoying as all get out. Media players that can manage AAC or MP3 files get confused by the dot files. At best they have to be skipped over.

So how do you get rid of 'em?

Well, in 10.0-10.2 you had to run use unix commands: macosxhints.com - Burn CDs without the invisible .DS_Store files.

In 10.2 or so the OS changed to burning hybrid CDs, a mixture of plain old Joliet and HFS+:

The .DS_Store (and many other mac-only metadata) files will be stripped from the crossplatform ISO/Joilet images. These files will still show up for the HFS side of hybrid images, so mac users will get them but other users on other platforms won't."

Some media devices still have trouble with hybrid CDs. I don't know about 10.5, but in 10.4 I don't think you can control this.

If you want to burn the simplest MP3 or AAC CDs for external devices, you need to specify PC Joliet as the Disc Type. In Disco ($20) and Burnz ($10) this is an option.

When you do this the PC view will not show any metadata or dot files.

Inexplicably, neither product explains why you'd want to do this. I guess they assume everyone understands that "PC Joliet" means no funky OS X metadata dot files.

Right.

Disco, by the way, has a problem in 10.4.11. When you insert a CD the finder blocks Disco's burn. No dialog is displayed, but nothing happens. I have to close all Finder windows to get it to work. I think there must be better options, I'm looking around.

Oh, and this is still a problem with thumb drives, at least in 10.4.

Update 6/9/08: I was really annoyed with Disco.app -- at one point it wouldn't burn no matter what windows I closed. Burnz didn't give me a simple enough control over what format I burned. Now I'm trying the free OSS app Burn.

The new world of Firefox bookmarks

This morning I watched a brief screencast on FF3, with a focus on Advanced bookmarking and tagging.

It's a terrific screencast.

The FF 3 bookmark and security features are even better than I'd realized -- and I've been running FF3 on my macs for weeks.

This is one heck of a browser launch. We're spoiled on the OS X platform now, with both Firefox 3 (blessed by Google) and Safari 3 (blessed by Apple) as excellent choices. The primary drawbacks of FF 3 for OS X are the lack of Cocoa integration (no services, no dictionary lookups) and the lack of AppleScript support (even less, currently, than FF 2). (I use Camino on my aging 10.3.9 iBook and I very much love its Cocoa integration. I'd really like to see a future version of FF 3 and Camino merging, perhaps adapting the tab management features of OmniWeb.)

Firefox 3 beats Safari by a country mile though when it comes to bookmark management. No more of that silly filing and organizing -- unless you REALLY want to do it.

One click to add any site to the unsorted collection. A second click (or a double click) to change the default name and add tagging. Tag model is similar to bloggers, easy to type or select from an on-the-fly dictionary (flat ontology). It's easy to see how well with will work with bookmark synchronzation and integration with web bookmark services. The search model is seamlessly integrated into the url field.

This is the way I've been managing my Outlook email for about two years now -- tagging, renaming subject lines, minimal filing for special projects, full text search.

Brilliant design.

Update 6/8: More great FF 3 features.

Vermeer/FrontPage lives in Sharepoint Wiki

This is a story of recursion and the rise and fall and rise of software. I'm one of the few people that could spot this particular example.

It began with Vermeer, later known as Microsoft FrontPage. I knew it well, even the Macintosh versions. Once, before it started drinking sterno and snorting meth, FrontPage was a software classic. I still use FP 98 on my XP box, there's never been anything better at creating hypertext documents.

FrontPage had a terribly swift decline after FP 98, but even in its debauched state it was the forgotten father of two bits of software - the early versions of Sharepoint and today's version of Sharepoint Designer.

I don't use SP Designer, but I use Sharepoint 2007 - a lot. Even on deep inspection there doesn't seem to be much of FrontPage left in the newest version. SP 2007 is an unspeakably awful document management system and file server, and a very clever implementation of a list/table manager.

Oh, and it includes a Wiki built on extensions to the list manager.

The Wiki is where the recursion comes in. As I worked with it, stringing together hypertext documents and switching between list and web views, the deja vu hit. I'd worked this way before.

The Sharepoint Wiki, I realized, maps very easily onto the actions and interactions of Vermeer/FrontPage. It's not as powerful or as quick to use as FP 98, but it's more approachable for novices and it doesn't require a thick client on each desktop.

So a shadow of FrontPage lives on, buried deep within Sharepoint.

Oh, and now I can explain to young folk the appeal of the original Vermeer/FrontPage. It's the super-powerful toolkit you wish you had for your Wikipedia writing.

Update 9/26/08: I had occasion to copy and paste a very long FrontPage document into a Wiki item. It rendered suspiciously well. I know Sharepoint Designer is a descendant of FrontPage, and that Sharepoint Wiki articles are editable using SharePoint Designer -- so maybe it's not surprising that Sharepoint Wiki is very accepting of FP HMTL. You really do feel the inheritance.

Access 2003 and bugs with special characters and escape sequences

Microsoft Access has some curious behaviors with certain characters. They can be very hard to reference in searches or text operations. Most software (ex. grep) uses “escape sequences” or delimiters for characters like #-()[]?* etc that may have special meaning, but Access struggles here.

From the Access Help files (which are impressive, but often like reading the scrolls of a long lost civilization), we can see that even the expected behavior is very obscure:

• Wildcard characters are meant to be used with text data types, although you can sometimes use them successfully with other data types, such as dates, if you don't change the Regional Settings properties for these data types.
• When using wildcard characters to search for an asterisk (*), question mark (?), number sign (#), opening bracket ([), or hyphen (-), you must enclose the item you're searching for in brackets. For example, to search for a
  question mark, type [?] in the Find dialog box.
• If you're searching for a hyphen and other characters simultaneously, place the hyphen before or after all the other characters inside the brackets. (However, if you have an exclamation point (!) after the opening bracket, place the hyphen after the exclamation point.)
• If you're searching for an exclamation point (!) or closing bracket (]), you don't need to enclose it in brackets.
• You can't search for the opening and closing brackets ([ ]) together because Microsoft Access interprets this combination as a zero-length string. You must enclose the opening and closing brackets in brackets ([[ ]]).
• A Microsoft Access project uses different wildcard characters than an Access database uses. For more information, search the Microsoft SQL Server Books Online index for "wildcard characters"…

I love the last bit, where Microsoft hints that even the odd rules Access once used won’t necessarily keep working.

As of June 2008 though things are worse in a patched version of Access 2003. I couldn’t get search on a [ character to work at all, and I had to escape a single quote using: """".

I think software ages at dog speeds, and Access is well into senescence.

Microsoft Access 2GB file size limitation and the Invalid Argument error message

Every time I ran “Make Table” in Access 2003 I got an “Invalid Argument” error message.

Google found the explanation in seconds:

Error message when you run an append query, run a make-table query, or import data in a large Access database file: "Invalid argument"

In Microsoft Access, when you try to run an append query, to run a make-table query, or to import data in a large Microsoft Access database file, you may receive the following error message:

Invalid argument.

This problem occurs when the size of the Access database file approaches the 2 gigabyte (GB) size limitation.

The limitation still exists in Access 2007.

Shades of the old DOS 640kb memory limits. Will we never escape those old 2**n boundaries?

Of course these kinds of meaningless error messages were impossible to decipher in the days before Google. It’s getting hard to remember how things worked back then …

iPhoto strips Finder metadata from image files on import in OS 10.4, fixed in 10.5

I've rewritten this post since original publication.

You can trace the evolution through this Apple Discussion thread: When you drop an image into iPhoto in 10.4.11 the Finder metadata (extended attributes – Spotlight comments, Labels, etc are not copied.

I thought this was an iPhoto bug, and I bemoaned the lack of attention to Finder metadata.

Apparently it's an OS bug! In 10.5 metadata, including Spotlight comments, is preserved.

So I can't blame the iPhoto engineers, but that's a pretty amazing OS bug.

OS X file renaming utilities: alternatives to ABFR

There are hundreds of splogs that claim to review software, but there's a simple trick to getting to the good stuff.

Once you come up with two product names, search for the two in combination. Then when you get to three, search for the three in combination.

Splogs can't auto-generate inter-product comparisons, so this blows away the junk.

I did this as I looked for an alternative to A Better Finder Rename for file renaming. I like ABFR, but I need to pay up again since my version won't work in Leopard (this is why OS updates are so expensive, the OS cost is the least of it).

Before I pay up, I need to scan the free alternatives. TUAW has a good quick review or 3-4 solutions - Name Mangler: batch rename your files,
and Renamer4Mac mentions 2-3.

I like paying for quality products, so I'll probably still pay for ABFR, but I'll at least try the best seeming of the freebies.