Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

haravikk

macrumors 65832
Original poster
May 1, 2005
1,504
26
I'm wondering if anyone else is having the same problem.

Basically, while I quite like the idea of the Resume feature, I don't like having it enabled system-wide, so I've locked my "~/Library/Saved Application State" folder in order to prevent applications creating folders inside, except for the ones I want (programs like browsers mostly).

Anyway, this works fine for the majority of programs, however, Preview seems to use some kind of non-standard mechanism for restoring previously opened documents, and it's driving me crazy, as most PDFs I view are really large files, so it means that forgetting to close one before quitting can make Preview really sluggish to open. However, locking the application state folder has had no effect on it, meaning it must store its state somewhere different, and disabling the the re-open windows settings using defaults write in Terminal has had no effect either.

Does anyone know where Preview keeps its application state? It's really annoying that it seems to use some kind of secret method rather than the same Resume system that every other app uses.
 
Hold down shift when clicking on Preview in the dock ??

Works for me - no previously opened files open......
 
While that does work, I'm really hoping to disable it permanently. It's a bit backwards to have to use special keyboard shortcuts to keep off a feature I only really want/need for a handful of apps.
 
In Terminal, enter:
Code:
defaults write com.apple.Preview NSQuitAlwaysKeepsWindows -bool false
and hit return.
If you ever want to turn it back on, just replace false with true.
 
I've used the defaults write trick on Preview, but it has no effect. Works fine for other apps, but neither locking the application state folder nor defaults write does anything for Preview. So it's still saving data somewhere but I can't for the life of me figure out where.
 
I've used the defaults write trick on Preview, but it has no effect.
Works for me on Preview, and everything else I've used it on.
Something is funny with your system.

Try trashing these files:
/Users/username/Library/Preferences/com.apple.Preview.plist
/Users/username/Library/Preferences/com.apple.Preview.LSSharedFileList.plist
/Users/username/Library/Preferences/com.apple.Preview.SandboxedPersistentURLs.LSSharedFileList.plist

Preview should create new, functional versions of each as needed.

The Terminal command should work for you.
 
Thanks Partron22! I could have sworn I'd tried deleting preferences, but perhaps I missed one; it took a couple of goes to get it to stick but it seems to have actually worked this time, hoping I'm not talking too soon…

On a vaguely related note, what is the actual purpose of the lock files in the preferences folder? I would have assumed these were only needed if the file was actually in use but they seem to be there all the time, and they didn't stop me doing anything to preferences files, including for running applications.
 
I just want to bump this, as the problem actually resurfaced not long after I thought it was fixed. Something is definitely not right with Preview, as I can open it by double-clicking a document and have that document only open, but then I'll quit and do the same thing and a document that I opened in Preview (but didn't close individually) will appear, even if it was a couple of application launches ago.

This means that Preview is definitely still storing open windows data somewhere, and it's definitely not inside ~/Library/Saved Application State, so where in the heck could it be?
 
Well, I finally figured out what was going on.

At some point Apple seems to have add the ~/Library/Containers folder, and inside this is a folder for com.apple.Preview, which stores a mostly symbolically linked structure for many of my user-folders. When I went poking around inside this I discovered that Preview had its own Saved Application State folder which is where it was saving its Resume data, instead of using the normal location at ~/Library/Saved Application State.

I can only assume that ~/Library/Containers has something to do with sandboxing, so programs can store files without worrying about conflict or security issues with other programs. It still makes no sense to me why this is being done for Preview's application state, which is stored using its identifier anyway, but at least the mystery is solved.

So for those interested the path is:
~/Library/Containers/com.apple.Preview/Data/Library/Saved Application State

In my case all I did was symbolically linked the above folder to the normal Saved Application State folder (which I've locked), which has restored Preview's normal behaviour. The same containers folder can be used to find Autosave Information folders for applications that insist on keeping everything even when you don't want it to :)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.