20581 Rate this article:

IDL 8.2: Time Machine Error Messages in IDL


Using IDL 8.1 or 8.2 on a Mac OS X 10.7 Lion or 10.8 Mountain Lion system, some users may experience a series of error messages in the IDL console window, which can make it difficult to properly see output. An error similar to this is observed:

2011-07-21 12:12:39.649 idl[11368:1603] This process is attempting to exclude an item from Time Machine by path without administrator privileges. This is not supported.

Note that despite the appearance of the error messages, the IDL session will actually continue to be functional and responsive to command input.

The remainder of this Help Article contains suggestions to suppress avoid the error messages described above.

Exelis Visual Information Solutions is working on a built-in solution to this problem for future versions of IDL. This Help Article will be updated as new information regarding this issue is available.


Workaround 1 (Requires Admin privileges) 

Note: The following steps have helped a number of users to stop these time machine errors in their IDL sessions. These steps appear to only be effective for the login issuing the commands below. For users without Admin privileges, see Workaround 3 below for an alternative approach to work around the problem.


To workaround these Time Machine errors with IDL on Lion, the following steps might help:

1.) From an X11 terminal window, enter a sudo shell with the command:

    sudo –s

2.) Enter your password, then issue the following commands. For IDL 8.2 (using a bash shell):

    . /Applications/exelis/idl82/bin/idl_setup.bash

For IDL 8.1:

    . /Applications/itt/idl/idl81/bin/idl_setup.bash

(Notice that there is a space between the "." and the first "/" in the above two commands that begin with ". /Applications/....")

3.) After the IDL session starts, exit from the IDL session. Next, from the same terminal shell, launch idlde:


After the IDL Workbench is done initializing, exit out of the idlde session

4.)  Finally, "exit" from the sudo shell to get back to a regular user shell.

After doing these steps, hopefully the Time Machine errors will stop occurring in the IDL sessions.


Workaround 2 (Avoiding the error by using the IDL Workbench instead of command line IDL)

If the error messages appear in the IDL Workbench session console view and the Workaround 1 does not suppress the errors, then another workaround is to launch the IDL workbench session from an XQuartz/X11 terminal window (rather than double clicking on the AppleScript icon or shortcut (Apple alias) to launch the product). For example (from a Bash shell):

    . /Applications/exelis/idl82/bin/idl_setup.bash

You can also start the IDL Workbench with an accompanying Apple Terminal by simply double-clicking on the following file via the Apple Finder:


By doing this the error messages should appear in the terminal window and not in the IDL console.


Workaround 3 (For users without Admin privileges; requires the assistance of a user with Admin privileges)

Approach A: Admin user runs IDL via "su" command from the affected non-admin user's login session.

1.) The affected non-admin user must first launch an affected session of IDL (where the "Time Machine" errors are encountered) and then issue the IDL "EXIT" command  to quit out of the IDL session, before the assisting Admin user  follows the steps below.

2.) Next, while still logged in to the Mac, the affected non-admin user should open an XQuartz/X11 terminal window.

3.) From the user's Terminal window, the Admin user should issue a command like the following:

For command line IDL:

    su -m joe-admin -c "sudo /Applications/exelis/idl82/bin/idl"

For the IDL Workbench (only at the local console display of the Mac):

    su -m joe-admin -c "sudo /Applications/exelis/idl82/bin/idlde"

--where they "joe-admin" should be replaced with the Admin's actual user name.  This command temporarily opens a new shell owned by the Admin user, where an IDL session is launched with "sudo" privileges.  (Note that the "-m" switch to "su" allows the original user's environment variable settings to be used in the new shell.)

(Note that because of the "su" and "sudo" calls in the command, the Admin user will need to enter their password a couple of times before the IDL session will start.)

4.) After IDL starts, issue the following command at the IDL> command prompt:


to exit gracefully from the IDL session.

Approach B: Admin user logs into machine, sets shell environment to affected user settings, and runs IDL.

1.) Rather than working from the non-admin user's login session (as in Approach A), an Admin user for the machine logs into the machine as him/herself

2.) The Admin user should open a Terminal window and then issue the following commands (for Bash shell):

    export HOME=/Users/joe-user
export LOGNAME=joe-user
export USER=joe-user
sudo /Applications/exelis/idl82/bin/idl

Or for IDL Workbench (running at the local display console of the affected machine), the last command should be:

    sudo /Applications/exelis/idl82/bin/idlde

3.) After IDL starts, issue the following command at the IDL> command prompt to exit from the IDL session:


4.) At this point the non-admin user should be able to run an IDL session without encountering the Time Machine errors.


 [ Reference IDL-63368 ]


1 comments on article "IDL 8.2: Time Machine Error Messages in IDL"

Avatar image

Roy Kilgard

I commented on this post before but my comment got scrubbed. These fixes work, but all of them involve per-user *and* per-machine effort by an administrator. If you have a large lab and large number of users, and you want each user to be able to login to each machine and run IDL, there is a huge effort involved.

To the person who included this line in the post above:

"Note that despite the appearance of the error messages, the IDL session will actually continue to be functional and responsive to command input."

Try using IDL for a couple of days when you have a deadline and this message popping up persistently. It's enough to make you translate your code into Python.

It's shameful that this bug has been around for 2+ years, through numerous IDL releases, and nobody has bothered to fix it.

Please login or register to post comments.