Restore hidden files from Time Machine

About backups

A working backup is like a stock of 10 billion masks waiting for a pandemic. You only use it when things go bad and since you never know when things go bad your backup needs to work flawlessly all the time.

Time Machine makes it extremely easy to restore anything that's on the backup disk to your machine. If you have not yet installed an external drive for your Time Machine backups, do it NOW. There is nothing more important than having a reliable backup of all your important files.

Time Machine has an optional setting (System Preferences > Time Machine > [Options...] button) where you decide what not to backup. Anything that is not there is basically copied to the Time Machine disk.

Hidden files are also hidden in Time Machine

This is not a Time Machine tutorial, so I'll stop here. But, what matters is that when you click on the "Enter Time Machine" menu item, macos shows a nice time based display of the contents of the current window, but it only shows what is visible. Not hidden files that are used in Unix applications as preference files and that are routinely created at the root of your home folder.

Yesterday I messed with one such file and since it was hidden, I could not restore it from the Time Machine display.

The easy way, for moderately experienced people

Time Machine can be accessed from the command line with the tmutil command.

$ man tmutil

TMUTIL(8)                 BSD System Manager's Manual                TMUTIL(8)

NAME
     tmutil -- Time Machine utility

SYNOPSIS
     tmutil verb [options]

DESCRIPTION
     tmutil provides methods of controlling and interacting with Time Machine,
     as well as examining and manipulating Time Machine backups.
     Common abilities include restoring data from backups, editing exclusions,
     and comparing backups.

The "verb" we're looking for is restore and its syntax is:

restore [-v] src ... dst
        Restore the item src, which is inside a snapshot, to the location dst.
        The dst argument mimics the destination path semantics of the cp tool.
        You may provide multiple source paths to restore. The last path
        argument must be a destination.

The src is where the restore date/time can be chosen since the backups have their own folders based on date/time.

So what I needed was:

$ tmutil restore /Time/Machine/path/to/.hidden.file ~/.hidden.file.test

I restored to a .test file just to make sure that really was the file I wanted.

The longer road, a half command-line, half GUI approach

Another solution is to make hidden files visible in Finder, start Time Machine, restore from the graphical interface and re-hide the files (they're hidden to avoid messing with them by accident).

There is no visible Finder setting that allows for that, so to get the job done one still has to use the command line to modify some non-GUI Finder setting from Terminal. This has been documented for years but I keep forgetting about it.

In Terminal, enter the following command:

$ defaults write com.apple.finder AppleShowAllFiles TRUE

What does all that mean ?

In Terminal, enter the following comment:

$ man defaults

To display the "defaults" command "man"ual. You should see:

DEFAULTS(1)               BSD General Commands Manual              DEFAULTS(1)

NAME
    defaults -- access the Mac OS X user defaults system

SYNOPSIS
    defaults [-currentHost | -host hostname] read [domain [key]]
    defaults [-currentHost | -host hostname] read-type domain key
    defaults [-currentHost | -host hostname] write domain { 'plist' | key 'value' }
    defaults [-currentHost | -host hostname] rename domain old_key new_key
    defaults [-currentHost | -host hostname] delete [domain [key]]
    defaults [-currentHost | -host hostname] { domains | find word | help }

(etc.)

Do you see the "defaults [-currentHost | -host hostname] write domain { 'plist' | key 'value' }" line ?

What that means is that the command syntax is:

defaults + optionally either "-currentHost" or "-host hostname" + write + the "domain" to which belongs the preference + a compulsory settings value.

In our case, the "domain" is "com.apple.finder", the "key" is "AppleShowAllFiles" and the "value" is "TRUE".

which means "Please, write down somewhere that Finder is now required to show all the files."

Next step

When you're done with your un-hiding hidden files, you can enter Time Machine, restore the file you want and then re-hide the hidden files with:

$ defaults write com.apple.finder AppleShowAllFiles FALSE

Et voilà !

Now, Finder doesn't know about that change of settings until you actually relaunch it. You can do that from Finder itself, or, since you're already in Terminal, you can do it from there by using the following command:

$ killall Finder

where "man killall" gives you:

KILLALL(1)                BSD General Commands Manual               KILLALL(1)

NAME
    killall -- kill processes by name
...

$ killall Finder

will actually kill and restart Finder.

To do the un-hidding and killalling in one fell swoop just tell Terminal that the two commands should be followed in order:

$ defaults write com.apple.finder AppleShowAllFiles TRUE; killall Finder

And the same for hidding them again when you're done with Time Machine:

$ defaults write com.apple.finder AppleShowAllFiles FALSE; killall Finder

Knowing about the command line is a must

Knowing about the command line and Terminal in a must. You can't pretend that system does not exist and trying to make sense of all that will drastically increase the amount of stuff you can do on your machine. There are plenty of tutorials on the web. One day I'll eventually write one for "us" translators, with commands that are relevant to our work...

OmegaT and the Okapi Framework plugin for OmegaT

Introducing the Okapi Framework plugin for OmegaT


This is a summary for people who want a "shortcut".

The Okapi Framework is "a cross-platform and free open-source set of components and applications that offer extensive support for localizing and translating documentation and software."


From very early on the people behind the Okapi Framework have helped OmegaT users with a number of facilities, among which the "Filters Plugin for OmegaT", which brings transparent support for file formats such as:

  • Doxygen-commented files
  • HTML files
  • InDesign IDML files
  • JSON files
  • Markdown projects.
  • Transifex projects.
  • TS files
  • Trados TagEditor TTX files
  • Wordfast pro TXML files
  • XLIFF 1.2 files
  • XLIFF 2.x files
  • XML files (with or without ITS support)
  • YAML files

Basic requirement

Make sure you have a recent version of OmegaT (use version 4 and above).

To use the plugin in OmegaT

  1. Enter your OmegaT configuration folder by using the Options > Access Configuration Folder menu in OmegaT
  2. If there is no "plugins" folder in that configuration folder, create one
    Create a "plugins" folder in the OmegaT configuration folder if it is not already there.
    Create the "plugins" folder if it is not already there.
  3. Download the plugin from the distribution site: https://bintray.com/okapi/Distribution/OmegaT_Plugin 
  4. Unzip if necessary, check the readme.html file if you want
  5. Copy the okapiFiltersForOmegaT-1.7-1.39.jar file to the OmegaT plugins folder that you identified above
  6. Restart OmegaT
Once you have installed the plugin, open OmegaT's File Filters preferences (Options > File Filters...) You should see a number of filters that have their name appended with "(Okapi)".

The Okapi plugin provides a number of additional filters that are identified in the OmegaT interface by the string "(Okapi)" appended to their names
The additional filters provided by the Okapi plugin

Et voilà.

Now, 3 things

  1. [obvious, but it doesn't cost much to repeat]
    If anything doesn't work as planned, carefully read the information in the links above and see that you have followed all the instructions and checked all the requirements. This article is only a summary.
  2. [beginner level]
    OmegaT already has native filters for some of the Okapi filters. If you want OmegaT to use the Okapi filters, uncheck the native filters.
  3. [advanced level]
    The Okapi filters have a default behavior that is reasonable enough. If you want to modify that behavior, you'll need to create a custom filter parameters file (
    .fprm extension) from within Rainbow. You'll use OmegaT's filter specific options (select the Okapi filter in OmegaT's Filter Filters interface, click on "Options...") to select that file so that OmegaT uses it.

    It is possible to customize the Okapi filters behavior by adding parameters files created in Okapi's Rainbow
    Adding a parameter file to customize the Okapi XLIFF filter behavior

Popular posts (last 30 days):