Until a few days ago one of my clients was happily using a Microsoft Access database which resides on a Windows file server. As of yesterday he was unable to open it due to the error:

This file is located outside your intranet or on an untrusted site. Microsoft Access will not open the file due to potential security problems.

Although a Microsoft KnowledgeBase article provides some advice it didn’t resolve the problem. A Google search revealed someone else experiencing this but “after tweaking their IE8 settings,” the problem persisted.

IE8 was not installed during my site visit a few weeks ago but it was worth checking - I remoted in. Sure enough, IE8 and a corresponding security update were installed. After a quick uninstall and restart the problem was solved.

I find it disturbing that Internet Explorer browser updates are still interfering with system-wide security settings and breaking software that was otherwise working properly.

I recently solved a problem on my OS X 10.5.7 installation where the coreaudio driver was in a constant “not responding” state and slowing down Final Cut Pro.

Aside from rebooting, a permanent solution involved removal of the CoreAudio plug-in from the system (details here). Since I’m not using the Digidesign equipment which uses this particular CoreAudio plug-in, my work wasn’t impacted.

Should you need to completely reinstall the driver for any reason you can grab them for OS X 10.5 and OS X 10.4.

It seems that only rare and obscure software glitches come my way.

Attempting to Compact and Repair a Microsoft Access 2002 database I received an error that “TempMSysAccess objects” already exists. In true Microsoft form there was no further explanation if the Compact/Repair operation had aborted-due-to-error or completed-with-warnings.

The error refers to an internal table used by Access and is hidden by default. Enable it via Tools / Options / View and “Show Hidden objects” and “Show System objects.” Delete the table and you’re good to go.

Solution found here.

The final presentation at last night’s Tapeless Workflow seminar at the Editors Guild was a discussion of tape backup. Yes, there were chuckles about the irony of a “tapeless workflow” which still requires tape media.

Melrose Mac was touting the merits of LTO-4 tape backup and underscoring its importance for securing production insurance, however I felt that LTO was presented as a near flawless mode of backup.

Unfortunately, it’s not.

Don’t Bet Your Life On It

During the course of my 17-year career building and managing server networks for large and small organizations I have implemented high-capacity backup systems on Windows and NetWare servers (remember them?) using many tape formats: DAT, 8mm, DLT, and the latest LTO.

Despite the lifespan claims of tape media, practical experience has shown me that tape backups are unreliable.

Any time I needed to restore data (for real) the tape backup system didn’t perform. Backup software would complain the catalog was corrupt. Tape media would become unreadable despite previous use.

A few weeks ago I attempted to restore data from an LTO-3 tape which was used 18 months ago - no luck - ARCserve informed me the tape was unreadable. This is what occurs most often despite the vendor, quality, price, format or tape media being used.

I’m guessing the LTO tape (which was created in a different [and defunct] drive) wasn’t readable in the newer unit - so much for standards. Considering that equipment is constantly changing you can’t risk unreadable media when equipment is upgraded.

Parting Thoughts

Regardless, tape is critically important to your backup strategy but is only one component. Suggestions:

• Create at least two copies on tape and external hard drive using media/device from different vendors.
• Fully restore them once a year and create new backup media.
• Rotate your media using a Grandfather, Father, Son scheme.
• Never be without multiple full and incremental backups spanning weeks, months, years.
• Securely store the media in different buildings, campuses, even cities.

This is my experience and, of course, your mileage may vary.

Other Options

Melrose Mac recommended a system from Cache-A which is plug-and-play and writes data in TAR (tape archive) format. Using TAR may eliminate software glitches such as corrupted backup catalogs due to software version differences (i.e.: ARCserve, Retrospect, etc.).

A few weeks ago our production’s Mac Pro suffered a RAID5 failure. Fortunately the data was recovered and we began to reinstall the system and core software, namely Final Cut Studio 2 (Final Cut Pro 6.05). As we sorted through our recovered data we noticed a number of problems with Final Cut Pro.

Incorrect Type and Creator Flags

Final Cut Pro would not open our project files due to an error of “wrong type.” Apparently the Mac still uses Type and Creator flags to determine what application owns a particular file (and why file extensions are still optional in OS X).

For unknown reasons most of the recovered data had Type and Creator flags that were reversed. What should be FCPF was FPCF, AIFF was FFIA, and so on. Due to the number of buggered files we used Quick Change’s batch feature instead of the console application setfile.

The proper flags are listed below (format, type, creator):

• Final Cut Pro project / FCPF / KeyG
• AIFF audio file / AIFF / hook
• WAVE audio file / WAVE / TVOD
• MOV media file / MooV / TVOD

With the flags fixed Final Cut Pro opened our project file successfully but greeted us with another error.

This Project is Unreadable

Opening the project file resulted with “this project is unreadable or may be too new for this version of Final Cut.” I wasn’t surprised because we rearranged our volume structure during the recovery.

I’ve covered this issue before which is due to Final Cut Pro using absolute paths within the project file.

Opening the project using a different user account does work because Final Cut Pro ignores the bad paths when the project’s user account doesn’t match. The project was exported to XML which revealed the paths as:

file://localhost/Macintosh HD/Users/name/path/to/media

This URL should open the related media file in Safari but doesn’t. Interestingly, localhost is stripped which leaves the URL as file:/// (an empty host); remove the third / and it will open.

Resolving the “project is unreadable” error is simple: create a user account with a different name than what was originally used to create the project (if you created the “old” user account, delete it). Open the project and reconnect the media - done.

Even with this accomplished I still could not open the project under the old user account. I’m curious to know what else Final Cut Pro embeds which isn’t easily changed.