Webspace of Eric Brodeur

Perspectives on storytelling and digital cinema technology

Archive for June, 2009

Windows logoIt 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.

Tape backup – don’t bet your life on it

Backup tape 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.).

Final Cut ProA 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.

Powered by WordPress. Theme: Motion by 85ideas.