Spotlight is generally very good at keeping a valid index of a drives contents up to date, but if you’ve recently restored a drive or had to delete the Spotlight index for one reason or another, you may need to reindex the drive manually. This is easy from the Spotlight control panel, and can also be achieved through the command line as we’ll demonstrate.

Reindexing Spotlight from the Command Line

Reindexing Spotlight from the command line is done with the mdutil tool, first launch Terminal and then type:

sudo mdutil -E /

This will reindex every mounted volume on the Mac, including hard drives, disk images, external drives, etc. Specific drives can be chosen by pointing to them in /Volumes/, to only rebuild the primary Macintosh HD:

sudo mdutil -E /Volumes/Macintosh\ HD/

To reindex an external drive named “External” the command would be:

sudo mdutil -E /Volumes/External/

Use of the mdutil command will spin up mds and mdworker processes as Spotlight goes to work.

Individually Reindexing Selected Files
In rare cases, Spotlight can miss a file during index, so rather than reindex an entire drive you can also manually add an individual file to the search index with the mdimport command:

mdimport /path/to/file

The mdimport command can be used on directories as well.

It’s easy to lose track of all the defaults commands used to perform tweaks to Mac OS X, but with the help of the history command it’s easy to list every defaults write and accompanying defaults delete commands ever used on a Mac. Launch the Terminal to get started.

See All Defaults Commands Executed

To see all defaults commands, including defaults write, defaults read, defaults delete, and even those requiring sudo:

history |grep "defaults"

Will return something like this:

47 sudo defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo HostName
48 sudo defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo IPaddress
98 defaults write com.apple.DiskUtility DUDebugMenuEnabled 1
206 defaults write com.apple.Safari IncludeInternalDebugMenu 1
237 defaults write com.apple.dock itunes-notifications -bool TRUE;killall Dock
238 defaults delete com.apple.dock itunes-notifications
239 defaults write com.apple.dock desktop-picture-show-debug-text -bool TRUE;
241 defaults delete com.apple.dock desktop-picture-show-debug-text;killall Dock

See Only Defaults Write Commands

To see only defaults write commands, including those requiring sudo:

history |grep "defaults write"

The results will look the same as above, but without showing any defaults read or defaults delete commands.

See Only Defaults Delete Commands

To see which defaults write commands have been reverted, grep for ‘delete’ rather than ‘write’:

history |grep "defaults delete"

See Defaults Commands Related to Specific App

By changing the text within grep to an application or process name, we can see which defaults commands were used only for that specific application. For example, to see only defaults commands that impacted the Finder:

history |grep "defaults write com.apple.finder"

Most apps are easy to find this way, and the default applications in OS X almost always follow the ‘com.apple.appname’ convention.

We touched on this concept before in a past post about the history command, but focusing on defaults commands is useful enough to deserve individual recognition.

Need to quickly encrypt a file from the command line? With OpenSSL, you can encrypt and decrypt files very easily.

For the purpose of this walkthrough, we’ll use des3 encryption, which in simple terms means a complex encryption algorithm is applied three times to each data block, making it difficult to crack through brute force methods. While we’re focusing on Mac OS X here, these commands will work anywhere that OpenSSL is installed, including older versions of OS X and Linux.

Encrypting Files with OpenSSL

The syntax of openssl is basic:

openssl [encryption type] -in [file to encrypt]

As mentioned before, we’ll use des3 for the encryption, and we’ll be using a text file as the input. We’re also going to specify a different output file to prevent any errors. Here is what the command would look like:

openssl des3 -in file.txt -out encrypted.txt

You will be asked to set and confirm a password before the encryption is complete, do not lose this password or you will lose access to the file.

Sidenote: You can also just use an input file with -in filename, but that may cause issues. To prevent any unexpected problems, do not specify the same file as the input and output. This means the original file will stick around either before or after encryption, and you will want to deal with that file individually, preferably through a secure delete method.

Decrypting Files with OpenSSL

openssl des3 -d -in encrypted.txt -out normal.txt

The previously set password will be required to decrypt the file.

Other than switching the placement of the input and output, where again the original file stays put, the main difference here is the -d flag which tells openssl to decrypt the file.

Naturally, you’re probably wondering what happens if you try to open an file that has been encrypted with OpenSSL without entering the password? You’ll probably get an error message, but if you force open the file with something like TextEdit, you’ll see the text “Salted” followed by a bunch of gibberish like so:

The file will remain unreadable until it has been decrypted through openssl again.

For more about file security, don’t miss some of our other posts, including password protecting a Mac, encrypting partitions, zip archives, files and folders in disk images, and even encrypting iOS backups to keep sensitive data from an iPhone and iPad secure.

The default behavior for most command line tools is to show sizes in bytes, for tiny text files that is fine but when you start working with larger items this becomes difficult to read and interpret. The solutions is fairly simple, pass a “human readable” flag with the command, which will convert bytes to a much more meaningful human readable format of kilobytes (kb) , megabytes (mb) , and gigabytes (gb).

Generally, seeing things as human readable is just a matter of passing an -h flag along with the command. Three prominent examples are with ls, du, and df:
ls -lh

df -h

du -h

Read on for some specifics about each:
Read more »

Mac OS X 10.7 Lion includes a great tool called tmutil that lets you interact with with Time Machine from the command line. It’s a powerful utility that has a ton of options and we’ve used it before to disable local snapshots, but for the purposes here we are going to use it to compare Time Machine backups. Launch the Terminal from /Applications/Utitilities/ and let’s get started.

Compare Latest Time Machine Backup to Macs Current State File by File

The simplest command compares the most recent Time Machine snapshop with what is currently on the Mac:

tmutil compare

The output can be fairly lengthy depending on how long you go between backups and how much data has changed. This is basically using ‘diff’ on the backup and current state, giving you a file by file breakdown of the differences. Files and paths with a + (plus) in front of them indicate it is new, files with a – (minus) in front indicate it has been removed, and a ! (bang) indicates the file has changed.

You’ll also see the size each individual difference, and at the end of the commands output you’ll find a summary of total sizes of what has been added, removed, and changed.

If you only want to compare file sizes, use:

tmutil compare -s

Compare Past Time Machine Backup to Current System State

Finally, if you’re wondering how an older backup compares to the current system state, you can specify the path to the old backup:

tmutil compare /Volumes/TimeMachineDriveName/Backups.backupdb/Macintosh\ HD/2011-11-02-129198

Replace “TimeMachineDriveName” with the name of your backup drive, replace “Macintosh HD” with the name of the primary drive, and replace the date on the end with which date you want to compare that is stored within the Time Machine backups directory.

You can monitor disk activity in Mac OS X by using the Activity Monitor app or several command line tools. Activity Monitor is the easiest and most user friendly, but the Terminal options allow further information to be retrieved.

Watching Disk Activity with Activity Monitor

• Launch Activity Monitor, located in /Applications/Utilities/, or you can hit Command+Space Bar to bring up Spotlight search and find it that way
• Click on the Disk Activity tab near the bottom
• The graph on the right plots Disk Activity
• Pay special attention to “Data read/sec” and “Data written/sec”

What’s causing the disk usage? Sometimes it correlates with CPU usage, and some apps and processes are heavy on both, like when converting video, audio, or Spotlights mds and mdworker. To know for sure, launch the Terminal from /Applications/Utilities/ and read on.

Monitoring Disk Activity from the Command Line

What is shown in Activity Monitor can be somewhat limited, and if you want information specific to what application or process is causing disk input and output, you can launch the Terminal and use the following commands to get more information:

sudo iotop -C 5 10

iotop will report back something like this, showing the overall disk read/write, as well as processes, command (or app) and the byte size being written actively by each process:

To easier compare apps and processes that are using the disk, pass the -P flag along with the iotop command, then pay attention to the % I/O column:

sudo iotop -P -C 5 10

iotop can also be narrowed down by disk drive by pointing at the path and using the -m flag. In the example below, the root filesystem only will be watched for activity:

sudo iotop -Pm /

The fs_usage app is another choice, although it’s a bit of a firehose:

sudo fs_usage -f filesys

fs_usage also shows disk reads and writes and the application or process causing them.

Using the lsof command, we can find out exactly what process or application is using a specified file at that given moment. This is similar to the opensnoop command, but rather than watching the changes to a file over time, lsof can give us a snapshot of this very moment, which can be helpful for troubleshooting purposes.

lsof /path/to/filename

For an example, to see what is interacting with with /var/log/system.log we point it at that file:

$ lsof /var/log/system.log
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Console 84281 Will 8r REG 14,2 140239 71929128 /private/var/log/system.log

In this case the app using system.log is “Console”. Again, this is showing us a snapshot at the moment the lsof command was executed, but by using the previously mentioned opensnoop command instead you can follow what processes use that file in real time:

sudo opensnoop -f /var/log/system.log

The above would result in seeing something like this:
$ sudo opensnoop -f /var/log/system.log
Password:
UID PID COMM FD PATH
501 84358 cat 3 /var/log/system.log
501 45411 console 3 /var/log/system.log
0 15 syslogd 16 /var/log/system.log

In this case you are looking under “COMM” for the process names, or PID for the process id.

Remember that you can go the opposite way with opensnoop as well, and show all files an app is using by pointing the command at an application or process, rather than a file.

Can’t use the easy Kext Drop app for some reason to install a kernel extension? Installing kexts (kernel extensions) manually is always an option and it’s not too difficult if you’re comfortable with the command line:

• Copy the .kext file(s) to /System/Library/Extensions/
• Open the Terminal and type:
• cd /System/Library/Extensions/

• Type the following commands at the terminal, replacing the kext name with the one you are installing

sudo chmod -R 755 kextfile.kext
sudo chown -R root:wheel kextfile.kext

• Now remove the kext caches:

sudo rm -R Extensions.kextcache
sudo rm -R Extensions.mkext

• Reboot the Mac

The kernel extension should now be installed.

As you can see this is more time consuming than the alternative, so ideally you’ll just one of the installer applications instead.

Thanks to Nick for the tip

Creating a password protected zip file is easy in Mac OS X and does not require any add-ons or downloads. Instead, use the zip utility that is bundled with all Macs.

If you’re familiar with the command line, the syntax of the encrypted zip command is as follows:
zip -e [archive] [file]

If you’re not sure how to use that, read on to learn how to create zip archives encrypted with passwords. These encrypted zip files will maintain password protection across platforms, meaning you can send a protected zip file to a Windows user and they will still need to enter the password in order to view the contents.

Set a Zip Password in Mac OS X

You can create password protected archives of files and folders:

1. Launch the Terminal from the Applications > Utilities folder
2. Type the following command:

zip -e archivename.zip filetoprotect.txt

3. Enter and verify the password – don’t forget this

The resulting archive, in this case named “archivename.zip”, is now encrypted with the password provided. The file that was encrypted, “filetoprotect.txt”, is now inaccessible without entering that password.

Example: Zipping a Folder and Setting a Password
Here is an example of what this will look like from the command line, in this case we are compressing and password protecting the entire ‘Confidential’ folder located within the users /Documents directory, and the password protected zip is being placed on the users desktop for easy access:
$ zip -e ~/Desktop/encrypted.zip ~/Documents/Confidential/
Enter password:
Verify password:
adding: ~/Documents/Confidential/ (deflated 13%)

Notice the password will not display, this is normal behavior for the Terminal.

Opening the Password Protected Zip

Despite being created at the command line, you do not need to unzip the file from the terminal, it can be expanded from the Mac OS X Finder or within Windows using standard unzipping apps. Just double click on the file, enter the password, and it will decompress. You can also decompress the zip archive from the command line with:
unzip filename.zip

Here are some use cases for password protected zip archives:

• Password protecting an individual file or directory
• Sending a sensitive and encrypted file over an unencrypted network
• Emailing confidential data to a Windows user
• Adding an additional layer of security to a hidden folder
• Password protecting your own backups, outside of Time Machine

While this can provide some protection on a per-file or folder basis, it’s always a good idea to password protect the Mac in general with a login requirement on system boot, wake from sleep, and waking from the screen saver.

Need to hide a folder or two on a Mac? A while back we showed you how to make invisible folders and to even how to make hidden folders in Mac OS X, but now we’re going to demonstrate how to turn an existing folder into a hidden folder.
Read more »