When you open a dmg or zip file (which we’ll refer to as an “archive” in this article), a tool called Archive Utility is opened briefly to extract the archive and then by default create a folder in the same directory the archive was located. After extracting the contents of the archive, the archive is left as-is, showing the new folder in a Finder screen. This type of workflow works for a lot of people. But not all.
This is why Apple built a Preference pane for the Archive Utility. To access, simply open Archive Utility, click the Archive Utility menu and click Preferences.
You then see the Archive Utility Preferences. Here, there are a few fields that can change the default behavior of how OS X handles archives. Each field is as follows:
The ability to control such features allows a data wrangler with a pretty well defined workflow to proceed much more quickly than would be otherwise possible according to how the person managing the data goes about their business. For example, if I know that every dmg file I get should be extracted, the contents moved to a share and then deleted, that can be the default behavior programmed and therefore I have less clicks of the mouse or steps to complete my process. Apple has, as usual, put good logical thought behind the default settings used. Therefore, be careful when changing settings.
krypted January 11th, 2013
Posted In: Mac OS X
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
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:
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.
krypted July 28th, 2011
Posted In: Mac OS X
Unzip items from the command line. For example, if you wanted to unzip a file called myfile.zip you can use the following command:
Or if you wanted to unzip all the zipped files in a directory you could cd to said directory and run this command:
krypted June 10th, 2007
Posted In: Mac OS X