Great Mac tar archive tip

Every now and then I just post things I don't want to forget or worried that the original website might disappear. This is one of the cases. This is a blog posting I came across on a little problem that plaques those of us that enjoy using OS X but have a need to move files to other systems like Linux and Windows.

There is a dirty little secret the Mac hides from you when you are using it but becomes a glaring eyesore when you move to another OS. Some file clean up needs to happen because OSX creates these hidden files that start with a ._ which contains some extended information about the file that no other system reads so they aren't terrible useful when moving files to these systems. This post from a person working for Splunk, outlines how to tar up files on a OSX machine that is targeted for other systems and exclude the ._ files from the tarring process. Original article can be found here

--------------- POST ----------------------

When building Splunk applications, I’m often working on a Mac. There
are files that begin with ._ that are resource files, which contain
extended attribute information about the files for the OS. This is
great and all but I don’t want to include these files when I package up
an application and upload it to SplunkBase.

If you don’t have deep OSX knowledge, then keeping these files out
of your tarball is harder than it looks. One of our OSX gurus pointed
me toward the answer, and I was so excited (yes, I am a geek) that I
just had to share.

To build a tarball in Leopard that doesn’t contain the ._ files, use:

COPYFILE_DISABLE=true tar cvzf filename.tar.gz dirtotar

In Tiger, use:

COPY_EXTENDED_ATTRIBUTES_DISABLE=true tar czvf filename.tar.gz dirtotar

This is definitely going in my .bashrc so I don’t have to fuss with it again:


--------------- PEND OF POST ----------------------

Fatal error: Call to undefined function: pn_dbmsgerror()

Had a strange error message on one of the sites I manage. It said "Fatal error: Call to undefined function: pn_dbmsgerror()". This is a Post Nuke CMS system and the error occurred after a reboot to the physical server and we made some space on a partition that had filled up.

Turned out the problem was a corrupted table in the Post Nuke database. The table _referer got twisted and didn't know what it wanted to do with itself. This table is only used for tracking where people come from who visit your site, so since I had a back up of the database, I just nuked the table and copied over the table from the back up database. That got everything up and running again perfectly.