krypted.com

Tiny Deathstars of Foulness

One of the new features that was introduced in OS X Lion is automatic application termination. This feature stops any applications that haven’t been used for awhile and then when you start the app back up, it fires up using the saved application state. But some processes shouldn’t be stopped. I’ve recently run into 2 cases where I needed to disable automatic termination. To do so is pretty straight forward: defaults write -g NSDisableAutomaticTermination -bool TRUE Once run, read the key back from the global defaults domain to verify it was run correctly: defaults read -g NSDisableAutomaticTermination The output should just be a 1. Provided it’s correct, now test that applications no longer automatically terminate. Provided they don’t then the setting can be left, or if your issue persists then you can just delete the key: defaults delete NSDisableAutomaticTermination While you shouldn’t have to restart for changes to activate, I do. Basically, at the relaunch of the app the changes should be active. Applications with network sockets should never stop taking resources; however, applications without network sockets that might call on them from time to time could be impacted. You can also look at doing per-application, as an example with Terminal: defaults write com.apple.terminal NSDisableAutomaticTermination -bool true Or Apple Configurator: defaults write com.apple.terminal NSDisableAutomaticTermination -bool true

June 3rd, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , ,

When Lion was new, I put up a post about clearing out information on saved applications states. Saved application states are a new feature in Lion that remembers the screens that were open and where each was when you quit applications. The reason for that post was that those states were causing a few minor issues with applications. There are a few applications that the saving of application states is really awesome for. I think it will mostly be different for each persons workflow. Personally I like saving the state of Terminal, Safari and a few others. However, the state of some others can be a bit annoying for me. For example, Word. Luckily, you can control which applications have saved states and which do not. To do so, first find the application in ~/Library/Saved Application State. These usually are the bundleid of the application followed by .savedState. Using the bundleid (or whatever is listed if not the bundleid), you’ll then send a NSQuitAlwaysKeepWindows key to the defaults domain for that id with a boolean setting of true or false. For example, to disable the saved state for Microsoft Word: defaults write com.microsoft.word NSQuitAlwaysKeepsWindows -bool false To re-enable it, just send a true value into the same key: defaults write com.microsoft.word NSQuitAlwaysKeepsWindows -bool true

September 16th, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

In Mac OS X Lion, applications can make use of a feature to auto-save and version files. This feature locks files that are inactive for editing and when the file is unlocked then starts automatically saving versions. If you have a problem with the file you can then always step back to a previous version of the file. The feature is manifested in the title bar and the file menu of applications that make use of it. When you open a file, it can be locked. Viewing the file in the Finder also shows that it is locked. Clicking on locked provides the option to unlock. Once unlocked you can make changes as you normally would. The next time you save the file, a version is created. Hovering the mouse over the title of a file results in a disclosure triangle. clicking that results in some options otherwise located in the file menu.

Clicking on the Lock option again locks the file. Files inactive can automatically be locked as well. The Duplication option is similar to that of Save As. You are asked where you want to duplicate the file to. No versioning information is sent with the file. These same options are in the File menu as well.

The command-S will still save a file, and in fact now it does more and it saves a new version of the file (also done as part of the auto-save routine). The Revert to Saved options in the File menu and title bar menu will bring up an interface similar to that of Time Machine. You can navigate through here to find a version that you want to restore and restore your data. Versioning information is persistent across a restore. In fact, once restored, you can revert back to a more recent save than that which was restored. In my testing so far, versioning information is not always persistent across restores of files (works with Time Machine, doesn’t work with 3 other applications I’ve tested). But YMMV there as patches are introduced in (hopefully) the next few weeks. Versions data is stored in /.DocumentRevisions-V100. In the /.DocumentRevisions-V100/db-V1 directory is a sqlite database with information and pages files are stored in containers by UID of local users in the /.DocumentRevisions-V100/PerUID directory. Permissions here are owner of root, group of wheel and d–x–x–x. bash-3.2# cd /.DocumentRevisions-V100/ bash-3.2# ls -al total 0 d--x--x--x   7 root  wheel   238 Jul 18 22:39 . drwxr-xr-x  36 root  wheel  1292 Jul 28 23:24 .. drwx------   5 root  wheel   170 Jul 28 23:27 .cs drw-------   2 root  wheel    68 Jul 18 22:39 ChunkTemp d--x--x--x   3 root  wheel   102 Jul 18 22:39 PerUID drwx------   4 root  wheel   136 Jul 28 23:27 db-V1 drwx--x--x   2 root  wheel    68 Jul 18 22:39 staging Changing the permissions to 000 causes the feature to report no versions for the files but then you also cannot save changes to files. If you remove the .DocumentRevisions-V100 directory altogether it does not automatically recreate itself at the creation of a new document; however, it does not create itself initially until the first time you’re saving a document. Putting the directory structure back in place resolves any saving problems (is all this sounding a bit like how Spotlight indexes work to anyone???). Versioning is saved locally for files that are stored on network volumes. If you move a file that was versioned locally to a network volume and back then it will loose versioning information. If you open a file from a network share there is no versioning information in the file unless the local computer you are using had been used to make those versions. When you save a file stored on a network volume you are informed that the volume does not support permanent version storage. If you open the file and start editing it on another host and changes occur on both hosts (which the system will allow to happen) then at the next save you will get an alert that states that the file has been changed by another application. Clicking Save Anyway will overwrite changes from the other computer and Revert will revert to the last saved document or more likely error out with a complaint about permissions (even if those permissions are 777). Continuing to make changes on both hosts will eventually cause a “GSLibraryErrorDomain error 1” error code; however, the file will remain open so you can copy your changes off into another file. A few other points of information:
  • Initially I had read that Time Machine was required to make use of this feature. That is incorrect. It works perfectly well with Time Machine disabled. Having said this, the app does report a message about Time Machine but this can safely be disregarded.
  • Initially I had read that it saves data into the ~/Library/Saved Application State directory. That too is incorrect. The state of versions-enabled applications is saved there but not the data
  • Large (> 500 page files) will auto-save very slowly if you have made a lot of changes in them. This is due to the fact that versioning results in copy operations.
  • Root can traverse into other users version files.
  • I have found no way thus far to change the auto-save interval (will hopefully update this when I do).
  • Pasting graphics into large files is much slower than previous versions (but likely offset by the new ability to flip through versions of files).
  • Not all applications have built-in Versions options yet (e.g. Office) but I think most will at some point in the future.
You can still mv a file to a .zip, unzip it and extract images and raw index data; however the versioning information is not actually saved there. Scanning the file system for changes during a version change only nets the file itself and the temp file (nested within /tmp) as having been altered. The Apple Developer Library explains Versioning as follows:
In the applications that ship as part of Mac OS X v10.7, users no longer need to save documents explicitly or be concerned about losing unsaved changes. Document-based Cocoa applications can opt into this autosaving behavior with a simple override. With automatic saving enabled, the system automatically writes document data to disk as necessary so that data displayed in a document window is, in effect, always the same as the document data on disk. A file coordination mechanism maintains sequential access to files. (See “Mac OS X File Coordination.”) Applications that support automatic saving also support document version history browsing. To browse previous versions of a document, choose Browse All Versions from the pull-down menu at the right end of the menu bar.
For more on NSDocumentController here’s Apple’s page for that. Overall, Versions has taken me a little while to get used to. Especially in TextEdit. But I’ll take the latency in exchange for the ability to roll back changes. If you are rolling out Lion in a larger environment, you’re going to want to check out whether or not users expect this to persist across network shares, copying files to additional computers or even backups in many cases.

July 28th, 2011

Posted In: Mac OS X

Tags: , , , , , , , , , , , , , , ,

Every new feature comes with its own troubleshooting as most will, if only eventually, have problems. Lion comes with a cool new feature where the state of each application is saved and when the application is re-opened the windows are just as you left them when closed, even in the same positions on the screen. This can be pretty useful with something like Terminal, where I often don’t restart the app for long periods of time because I want to see my recent history across multiple sudo’d users. When you open Terminal, the previous commands are grey, but there. But I’ve run into a few instances where an application crashed and continued to do so upon restart. The way I was able to remedy this was to trash that application’s Saved Application State directory, kept in ~/Library/Saved Application State. Each application should have an entry in here using the typical property list format naming convention (e.g. com.krypted.myapp.savedState). Trash that folder with the app closed and it will open fresh and clean. To do so (continuing on with the com.krypted.myapp.savedstate example): rm -Rf ~/Saved Application State/com.krypted.myapp.savedstate Finally, it’s worth noting that some applications store certain aspects of saved states in their default domain. So if you’re clicking on a tab in a System Preference pane, keep in mind that to reset some things you might need to locate the correct plist file and nuke the settings within the plist.

July 21st, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,