Get rid of .DS_Store files from GIT Repo on Mac OS X

Whether you are new to GIT repositories or an experienced developer, I am sure, at some point in using GIT, you must have come across these annoying .DS_Store files that seem to populate out of nowhere. It is a much apparent problem if you have enabled viewing hidden files.

What are they? DS_Store is a short form for Desktop Service Store that contains attributes of a folder and is created every single time a folder is navigated to. The more you navigate through your program source code, the more .DS_Store files you will end up finding. You can delete them but they will appear again.

I am okay with seeing them on my Mac but when you have an auto deployment script setup for GIT, you prefer not having these useless files on your Linux machine. We use a neat little auto deployment script which gets executed each time new updates are pushed to our repository. We have a repo for each of our business applications so it saves our developers plenty of time navigating their way through FTP programs and updating files through that.

To help address this issue, you can configure GIT globally to ignore .DS_Store files by executing this the following:

git config --global core.excludesfile ~/.gitignore

OR, if you already pushed some of these .DS_Store files, you can get rid of them from your repo in the following way. Go to the root of your app directory and execute the following command in terminal:

find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

That will get rid of all recognition of .DS_Store in your repo. Next, add the .DS_Store to the ignore list. You can do that by simply creating a .gitignore file. Place the following in the .gitignore file at the root of your app directory.


Save it as .gitignore and push the changes through. Voila! One less annoying problem to worry about 🙂 I am still giving thought towards publishing the source code for our Auto Deploy script 😉


You do not have the SUPER Privilege and Binary Logging is Enabled

Recently while trying to upgrade our project management app, I encountered this error, “You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)”.

What we initially thought was the lack of TRIGGER privileges for that MySQL user. But even after giving the MySQL user all necessary privileges, we continued to experience that error during a backup process. By the way, you would need to specify the SUPER privileges for the user running the import into the database along with the CREATE ROUTINE, ALTER ROUTINE, CREATE TRIGGER, ALTER TRIGGER, CREATE FUNCTION and ALTER FUNCTION privileges. We use Amazon RDS for storing and managing data across all our websites and as many of you might be aware, Amazon isn’t keen on giving super privileges to users of their system.

To fix this issue, here is the solution that worked for us…

1) Open the Amazon RDS Console.
2) Go to the “Parameter Groups”
3) Create a New Parameter Group (You can add to existing custom parameter group if you got one). On the dialog, select the MySQL family compatible to your MySQL database version, give it a name and confirm.
4) Click on “Edit Parameters”
5) Look for the parameter “log_bin_trust_function_creators” and set its value to ‘1’
6) Click on “Save Changes”
7) Open “Instances” and Expand your Desired MySQL Instance
8) Click on “Instance Action” and Select “Modify”
9) Select the Parameter Group and enable “Apply Immediately”.
10) Click on “Continue” and Confirm Changes

It’s best to reboot for changes to reflect. Select the instance and reboot your MySQL instance. That should do the job. For those of you on traditional MySQL environment, you can specify the log_bin_trust_function_creators option in two ways.

1) Specify on Server Start as this “–log-bin-trust-function-creators=1”
2) By setting it to “1” using a Global Statement

mysql> SET GLOBAL log_bin_trust_function_creators = 1;

Alternatively, If you are not planning to use your MySQL server for the replication consider turning the binary logging off by removing the option –log-bin from the command options for the mysqld utility starting that MySQL server. Hope that helps developers experiencing similar issues with importing and exporting SQL or should I say, while creating a dump 😉


Linux/Unix Commands for Unzip GZ Files

GZ is no doubt one of the best choices for database compression. We use it quite often when importing and exporting files. In fact, we recently used it for migrating our MySQL databases to Amazon RDS.

To extract a GZ file, use Gunzip command:

gunzip file.gz

If that had no success, try this:

gzip -d file.gz

To check if new extracted file exists, enter the following:

ls -l