One of my favorite software is Max Bulk Mailer.
ON a new blast, for some reason, old images are showing, even though I've swapped out the image jpeg.
The developer says he is using the Safari webkit.
I emptied safaris cache (don't even use Safari anymore)
Ran Cocktail, full cache clear on that software.
Even deleted the safari cache in preferences, Cache folder, no luck.

When you sent out the email, did it have the picture embedded inside the email, or did it load the picture from a Web site?

thanks Tacit.
For the actual email blast, the images are hosted on my website.
The blast test came in fine and correct with the new image.

But it's the preview in Max Bulk Mail which is the issue.

It's disconcerting to see in your current preview, the image from last years blast.

Any idea how to clear this cache, wherever it is?

I don't know anything about that particular program, sorry!

thanks Tacit! You don't need to know about the program to help.
The developer knows the program inside and out and cannot tell me why the cache is stuck on my computer.
HE said he uses Safari tookit -- whatever that means.

This is from my help ticket with him:

To developer:

I duplicated a max blast. Changed some text and swapped in a new image (jpeg)
everything looks great and tests fine. But for some reason the image in the preview within max shows the old image, even though that image was deleted off the server!

Kevs

MaxBulk Mailer uses the Apple Web Kit as Safari. I guess it is a cache problem. Yes but MaxBulk Mailer uses the Apple Web Kit as Safari and the only explanation is some cache somewhere. When you don't see in the preview what is intended, usually something older, it is because of a cache. MaxBulk Mailer doesn't use any but Web Kit does.

Keys, I have been following this thread and had nothing to contribute, but at your request I took another look at it.

Like Tacit I am unfamiliar with the product you are using and the guess about it being a cache problem is as good as anything I can come up with. When I was earning my bread and butter as a software design engineer I ocassionally saw similar problems caused by failure to do garbage collection in the code — essentially failure to flush a memory cache internal to an application — or an incorrect API (Application Program Interface) call possibly to to the webkit. But without access to the application source code and potentially a lot of debugging time that will have to remain as speculation or to be more accurate a wild guess.

thanks Joe! oh well, I'll email developer I tried.

You're a developer, so perhaps you can clarify this:

> MaxBulk Mailer uses the Apple Web Kit as Safari. I guess it is a cache problem. Yes but MaxBulk Mailer uses the Apple Web Kit as Safari and the only explanation is some cache somewhere. When you don't see in the preview what is intended, usually something older, it is because of a cache. MaxBulk Mailer doesn't use any but Web Kit does.

I know nothing about either developing apps or WebKit, but it just does not seem likely to me that a developer does not know where his app's "stuff" is cached.

Is it actually possible that MaxBulk Mailer just "throws" "stuff" at WebKit which deals with it according to its own secret protocols or, as seems more likely, does WebKit handle "stuff" as instructed by the apps with which it interacts (if that's a correct word in any sense)?

Thanks.

OS X and iOS provide developers with literally thousands of Application Program Interfaces (a.k.a. APIs) that provide immense power and functionality to developer applications. Functions such as creating windows on the desktop; accepting keyboard, mouse, trackpad input; rendering screen images from HTML, CSS, Javascript; providing internet access; etc., etc., etc. All the applicaton developer needs to know is the API call and what parameters are needed to perform the task and what parameters to access to obtain the results of that call. There are numersous advantages to this scheme including:

• Each developer does not have to "reinvent the wheel" by writing extensive code to handle common functions.
• It dramatically reduces the opportunity for error in the applications because much, even most, of the finicky stuff is handled by proven code in the OS
• It contributes to a common "look and feel" for all applications
• It dramitacally reduces the possibility for applications interfering with one another or with the OS
• The application "footprint" on the hard drive and in memory is generally a fraction of what it would be if all the functionality were resident in the app itself
• Applications are a lot easier to develop and therefore can be profitably sold at mucb lower prices
• It makes a substantial contribution to Apple's mantra that "It just works"

A side effect of these extensive APIs is that is entirely possible to develop good applications with little or no knowledge of what is going on under the hood. Think of it as the developer's version of "It just works." While information on the specific code used in these APIs (what you are calling protocols) is not always available, how they work and what they do is available to anyone who is a registered Apple Developer (even at the free level) and has the time and patience to rummage through hundreds or even thousands of pages of documentation. Although there are some really bright and well informed guys and gals developing applications for OS X and iOS, Apple has made the entry point easy enoough that I would venture a substantial portion of those developers do not have the background to comprehend how those APIs work and could care less.

So it is entirely possible, even likely, that a given developer has little or no idea where webkit puts "stuff" or how it works internally. No matter what you think of this, trust me, you do not want to go back to the bad old days of software development where everyone did their own thing. By the way like almost everything in OS X and iOS, webkit and its associated APIs, is an open source product used by lots of developers other than Apple.

Thanks guys, not sure the deal. the issue still persist. The developer says he has only heard of this issue one other time in 10 years. I can solve it by renaming future jpges, but I was hoping to just inset new image with same name -- but alas, the old image still shows in his software.

(I even could keep same name, and verify through email test, but just wont see the accurate new image)

Great post... Thanks!

I grew up taking things apart just so I could see how they were put together, and the concept of using "prefabs" without ever knowing what they're made of or how they work is anathema to me.

Edit: But I certainly get both your point and the point of the whole setup.

I understand your unease, but when you are dealing with systems containing hundreds of thousands of lines of code written in a style that is intentionally designed to make the internals invisible (ie. Object Oriented) it quickly begins to make a lot of sense.

Can't argue with that!

Now, back to troubleshooting... This thread, which apparently deals with a cache issue, has come this far without anybody having suggested that kevs clear caches, and in that regard I'll ask which utility would you, and everybody else, recommended for clearing some unknown cache, somewhere, possibly/probably a component of WebKit?

"applejack AUTO" comes to mind, but I've never investigated its functionality in depth, and I've got zero knowledge of the other 3rd party utilities...OnyX, Cocktail, Snow Leopard Cache Cleaner, etc.

Further, there are a skebillion caches in an OS X installation, and even if I were 100% familiar with all of the utilities I still wouldn't know whether any of them cleared the cache at issue.

The utility I would probably use is Tinkertool System (the shareware product not the freeware Tinkertool) as it seems to offer more control over what caches are deleted. But, I would not guarantee it, or any other product, would delete all caches.

Thanks... Ball's now in kevs's court.

I've used Cocktails clear caches, no improvement with this micro issue thanks.

You missed the point, kevs... Nobody knows which particular cache is at issue (and Cocktail is not the most robust of the various cache clearing utilities), which is why I asked joemike et al which utility may have the best chance of clearing the apparently obscure cache you're having your problem with.

If you're really interested in bringing this issue to a close, you ought to give TinkerTool System a shot. ("You can download the product and fully test it for a limited time before you decide to purchase an unrestricted usage license.")

ok Art, downloaded Tinker tool, where is the cache delete there? Can't find it. thanks.

From TinkerTool System Release 2: Details (scroll down to "Features in Detail"): The features marked with an asterisk (*) below are available without any restrictions even if TinkerTool System runs in demo mode.

None of the cache-related functions is marked with an asterisk, which suggests that they may not be available in demo mode.

Are you sure you downloaded TinkerTool System 2 and not the freeware TinkerTool? In the TinkerTool System 2 main menu the top row of icons is labeled "System Maintenance" the second icon from the left looks like a blue recycle bin and is labeled Caches. Click on that icon and there are three tabs

1. Application-Related caches
2. Font Caches
3. Startup Driver Cache

Under the first two there are multiple options for caches that are to be deleted. The options are pretty self-explanatory but if you have more questions TinkerTool System Help has detailed explanations of each.

SInce I have registered copies of TinkerTool System 2 installed on all my Macs, I don't know which, if any, of the functions are disabled in the trial version.

Thanks Joe, DK,
this is what I have now:
http://imageshack.us/photo/my-images/824/screenshot20110617at959.jpg/

If there is a better version, do you have a download link? I think I got this from their website, so I'm bit puzzled....

That is not TinkerTool System, to which I linked.

That image is TinkerTool not TinkerTool System. The download for TinkerTool System is here.

Ok got it and it worked, great call guys!
Just checked everything in cache boxes -- 4 of them did the reboot, problem solved (until it comes back...)

Any reason to keep/ use Cocktail? Seems Tinker tool more robust correct?

Cocktail runs those basic scripts and does a disk permission, and does say it clears systems, user and internet cache, but it did not solve it as Tinker did

I have Cocktail, OnyX, MacPilot, and TinkerTool System. And at any given point in time for any given situation I may use any one of the four. However, each has its strengths and weaknesses.

• Cocktail is the only one of the bunch that can be set to run and perform specified tasks automatically. I used to run several things such as permission repair every week using Cocktail, but that began to seem unnecessary and I no longer use the automated functionality of Cocktail. Others will certainly differ with my current practice -- it is most a matter of personal taste and opinion.
• OnyX has the undeniable advantage of being FREE.
• MacPilot has a growing list of "Tools" such as rebuilding the Launch Services database but it lacks features offered in most of the other utility apps mentioned. MacPilot's primary usefulness is providing access to over 1,000 otherwise hidden preference settings in almost every OS X app as well as the system itself. I am continually amzed by the number and variety of hiddes preferences in MacPilot.
• TinkerTool System offers configuration and tuning tools not otherwise available in other apps as well as a tool for creating and managing Access Control Lists which is seldom needed but invaluable when it is needed. As I mentioned before, I find TinkerTool System offers more fine tuning options than others and has become the utility I go to first when I want to do something. But that is a matter of personal taste and others can and will disagree with me on that.

Joe,
interesting.
Cocktail: so you don't use it anymore then?
Onyx -- if something is free but you don't need it, then why have it? It's just clutter.
MacPilot -- Launch services -- never heard of that. Of course I don't know a lot of things until a problem arises.
Tinker Tool. I'm amazed it solved this issue. Which cache did it flush that Cocktail did/could not?

This is what I run once a month:
http://imageshack.us/photo/my-images/862/screenshot20110618at938.jpg/

Now I don't believe in upgrading Cocktail if Tinker tool is better. But I don't think Tinker tool has a button that will run the scripts, the caches, and the repair permission in one fell swoop right? With Tinkertool it seems you have to tab through several tabs and click several buttons which is tedious.

Joe, I would love to see you list of monthly maintenance. Once month I click that button in cocktail and I repair each hardrive manually. that's my monthly maintenance for my imac.

Just for clarification for other readers of this thread: This is TinkerTool System (shareware), not TinkerTool (freeware), right? They do differ as to what they can do. The better one is, of course, TinkerTool System.

I got the paid system 2 everyone mentioned.

Perfect. I think it is an interesting thread comparing various maintenance apps for cache clearing. So, the consensus is to recommend TinkerTool System at least for this particular task. It also shows that other apps claiming to do the same thing fail to do it right. Always good to know. Thanks, kevs, for bringing this up.

On the contrary I do use it on occassion as needed but I do not have it set up to run at a regular interval
I have it primarily because so many people use it that I like to have it around for testing and to verify things I post on FTM

Agreed, but notbing can touch MacPilot for configuring OS X and OS X applications using hidden preference settings to fine tune your use of applications and the OS itself.
In the first place TinkerTool is not what you used. You used TinkerTool System. Both are written by Marcel Bresink. TinkerTool was probably the first OS X configuration utility ever written and I have used it since OS X 1. TinkerTool System came along much later and as I said previously there is no overlap in functionality between the two other than TinkerTool System's ability to import the TinkerTool panes into its own GUI.

As OS X has matured I have gone from regular maintenance routines to a philospy of If it aint broke — don't fix it. The closest I come to regular preventative maintenance is continually running TechTool Protection or Drive Genius' Drive Pules routine in background to monitor drive health and provide early warning of volume damage or impending drive failure. Every six to 12 months I will use either TTP or DG to defragment and rebuild the volume structure more out of habit than anything else.

Hmm... but we don't really know which cache was cleared, that (allegedly) nothing else would remove. It would have been real nice to know which file was causing the problem... so we're still left with something of a mystery here, [and that's far from "perfect".]

Mac, ok! cool.

Joe:
"configuring OS X and OS X applications using hidden preference settings to fine tune your use of applications and the OS itself."

What does this mean? never heard of hidden preferences.

So the more expensive system 2 does not have Tinker Tool regular on it?? odd no? Boy, it's got so much on it though.

Do you really need to monitor drive health?

H - I agree, I would love to know how Tinker Tool system 2 did what Cocktail could not. (remember, the owner of the software in question -- extremely smart developer) -- did not know.

> [...] that (allegedly) nothing else would remove.

As I said, my first inclination was to suggest "applejack AUTO" (but I suspect that would have been futile); either it or SL Cache Cleaner, which I believe also has "deep" cache cleaning functionality, may very well have turned the trick.

Yep, AppleJack is pretty thorough, and —since it works from single-user mode —it has no competitor when login and/or normal startup is not possible (the only condition being it needs to be installed ahead of time).

Bresnik gives a good description of that particular TTS feature here: The Pane Caches

idunno, all of the apps mentioned in the posts above have various options for cache cleaning... and i'm not sure if “i tried that and it didn't work” tells us the full story.

In the end however, there are only a handful of 'standard' places where caches are supposed to be placed... and i'm not aware of (read: don't believe in) any secret locations which would require any special tricks.

$ sudo -s
Password:
# ls -d /var/folders/*/*/-Caches- {,/System,/Users/*/,/var/root}/Library/Caches
/Library/Caches
/System/Library/Caches
/Users/halito/Library/Caches
/var/folders/Ap/Ap8ZG0DPEpu2FgJTwuRPoU+++TI/-Caches-
/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++4U+++-c/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++EE+++22/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++KE+++3Y/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++L++++3k/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++ME+++42/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++nE+++Ao/-Caches-
/var/folders/zz/zzzivhrRnAmviuee++++p++++BE/-Caches-


Names may differ slightly below /var/folders, but the blue command should work for all Leo/Snowy machines.

Edit: the ls -d command just lists the names of those folders. To see their content, change -d to -la or something.

Edit 2: changed the above command sequence to grab a root shell first. (shell pattern matching requires it to "see into" other user accounts)

Edit 3: hmm... for completeness, i added /var/root/Library/Caches as well... but it appears "empty" here so far:

--

While that covers what are technically considered cache locations... there are a similar number of "temporary" files which could be dispensed with as well (though one would hope a regular old restart would clear same).

--

Admittedly, searching my own library for 'cache' in folders other than Caches produces way too many results:

find ~/Library -not -path '*/Library/Caches*' -iname '*cache*'

[meaning: some apps don't always put "cache data" where they're supposed to.] And who knows what sort of data which should go into a cache area isn't actually winding up stuffed inside a plist in Preferences?

There are over 1,000 preferences for OS X and OS X applications such as Finder, Mail, Safari, AddressBook, Disk Utility, and some 28 other Apple and common third party applications that are not accessible through the Preferencee settings in the GUI Because they are not available through the Preferences GUI in the applications they are called hidden preferences. They are not secret because they are available to anyone willing to spend the time to dig through thousands of pages of developeer documentation to ferret them out. The developer's of MacPilot have done this however, and present them in a single application. As I said there is no overlap between TinkerTool and TinkerTool System, but if you have TinkerTool installed on your system — it is after all free — TinkerTool System can import the TinkerTool configuration panes into its GUI.
In my experience the most common system failure in Macs or PCs is hard drive failure, and it seems HD failure is becoming more common. Monitoring volume and drive health can provide early warning of impending failure and allow you to take appropriate action to repair volume structure damage, or move the data off of a failing drive before it fails completely and the data is unrecoverable. Just last week DG a;erted a friend his drive was failing and he was able to get his most critical data off of the drive before it failed totally. My experience is the failure rate of hard drives is three to four times that of other hardware components. So I will leave it up to you whether monitoring volume structure and drive health is worthwhile. I think it is.

As a side note, my experience and that of an extensive test by Google Labs is the S.M.A.R.T. values touted by manufacturers and used by all sorts of different utilities is a good indicator that a drive has already failed and you just don't know it yet, but a poor predictor of impending failure. TechTool Pro provides more data on S.M.A.R.T. results than any other utility I am aware of and is therefore better at predicting drive failure than the summary reported by Disk Utility, Diskwarrior, OnyX, and numerous other utilities. The best predictor of impending drive failure is a surface scan which typically takes several hours to complete. Either TechTool Pro or Drive Genius can perform a surface scan, but it is not part of either utility's monitoring utility.
Comparing the logs or perhaps the documentation of the various utilities should reveal this answer.

Joe,
thanks.
I"d love to hear of a few real world examples of hidden preferences.
I added Tinkertool regular. It came up at bottom of system pane as user settings for my home folder name.
You recommend Tech Tool Pro over, DG (what DG stand for again?)
I never really liked tech tool, seemed unstrustable when I ran things, but maybe it's better now.
You run it manually one time a month?
If my drive fails I have a clone that gets backup up every night. and one in the bank safe deposit.
Do you still use Dick Warrior? I use to love that, but have not updated with the better performance of drives lately.
Logs: I would have no idea on that... but I now have my copy of Tinker Tool system to solve this issue in the future.

PS Joe, I downloaded Macpilot to take a peek, but don't see where this feature is to see hidden preference. Maybe you have a software everyone knows I could understand it.

To help you with real life preferences, you can make the invisible files visible using some Finder commands, or, easier, with a small utility InVisibles (http://www.macupdate.com/app/mac/12194/invisibles).
If you then open your Users/yourname/Library/preferences folder you will see a whole bunch of hidden (invisible) preferences starting with .global.
Just an example.

I know of invisible files, but Joe is talking about hidden preferences. I'd love to see some apps I know and love hidden preference and where macpilot does this.

I don't think what Joemikeb and kevs are discussing are invisible files; they're discussing hidden preferences—an entirely different matter.

Here's an example. When Leopard was nearing release, a number of developers were unhappy with the 3D Dock, its glossy shelf, and the subtle blue orbs of light indicating running apps. Ultimately, an option to revert to the Tiger-style 2D Dock was included in the final version of 10.5, but without any GUI (Graphical User Interface) means of accomplishing such a reversion.

To revert to the 2D Dock, one has to go to Terminal and enter

defaults write com.apple.dock no-glass -boolean YES; killall Dock

[or, in deference to ganbustein's point about the undesirability of using killall in this fashion, one can run the following Applescript script instead:

tell application "Dock" to quit
do shell script "defaults write com.apple.dock no-glass -boolean YES"

which works on my Mac (OS X 10.5.8), though since the Dock, once quit, automatically relaunches, it's conceivable that if the shell script were delayed, the relaunching of the Dock would precede it, thus negating any change.]

And once one has reverted to the 2D Dock, one finds the following entry in ~/Library/Preferences/com.apple.dock.plist:



Note that although this "no-glass" key is nowhere to be found if you've never reverted to the 2D Dock—i.e., it's hidden—the file it appears in once you do revert to the 2D Dock has been visible all along.

But ironically enough, enabling invisibles in Finder does involve accessing its hidden pref...

defaults write com.apple.finder AppleShowAllFiles -bool TRUE

...so, it's all relative.

[edit: actually, no irony perhaps... that's probably exactly what Alex meant to convey.]

Ok, DK, thanks! that's a pretty arcane app, but I get the idea.
Not sure Macpilot can help with hidden preferences for my apps like Office, Photoshop... but who knows!

The Dock is the one exception to the rule. Since it won't stay quit, quitting it doesn't really help. It may even make things worse, by starting a race between how quickly you can update its prefs and how quickly it can read them.

For the Dock only, you have to just take your chances and use kill (or killall). The only mitigating factor is that Dock needs to update its preferences so rarely, basically only when you drag something in/out of the dock, or drag the dock to a different edge of the screen, that it (apparently) can afford to flush every minute change out to disk immediately. It never has any unsaved changes in RAM, and is never writing anything to disk except while your hand is still on the mouse/trackpad from telling it to do something. (I.e., your hand isn't on the keyboard running a command in Terminal.) Apple knows that there are a kajillion instances of "killall Dock" advice out there on the interwebs, and they've (apparently again) hardened it to survive.

At least I hope so.

Finder, on the other hand, is constantly updating its in-memory copies of .DS_Store data, as you navigate your windows from folder to folder and/or change views and window sizes. To be reasonably efficient, it has to flush those changes to disk only occasionally and at unpredictable times.


Assuming that "killall Dock" is safe, you can use it to tease Dock. (You can make it slightly safer by telling Dock to quit, and then proceeding with the game after it comes back. After it quits normally and restarts, you can be sure its pref files are up-to-date, and killing it should be benign.)

The tease has to do with the genie effect as it sucks a window that you're minimizing into the dock. You can put the genie effect into slow motion by holding down the shift key as you click on the yellow minimize button.

In a Terminal window, type the command killall Dock, but don't press return yet. Be sure the window is in a place you can reach quickly. While holding down the shift key, click on the minimize button of some other window. Then, very quickly, click back in the Terminal window and press return. (Alternatively, keep the Terminal window in front, and minimize some window in the background. That way you don't need to click on the Terminal window. The killall Dock command doesn't need to actually be on screen.)

Try it with the Dock on various edges of the screen. Try interacting with the victim windows. (Keyboard navigation helps.)

As a reminder, some pertinent Dock settings are (usual setting is blue):

defaults write com.apple.Dock mineffect -string genie ; killall Dock
defaults write com.apple.Dock mineffect -string suck ; killall Dock
defaults write com.apple.Dock mineffect -string scale ; killall Dock

defaults write com.apple.Dock orientation -string left ; killall Dock
defaults write com.apple.Dock orientation -string right ; killall Dock
defaults write com.apple.Dock orientation -string bottom ; killall Dock
defaults write com.apple.Dock orientation -string top ; killall Dock

defaults write com.apple.Dock pinning -string end ; killall Dock
defaults write com.apple.Dock pinning -string start ; killall Dock
defaults write com.apple.Dock pinning -string middle ; killall Dock

(Darn! orientation top no longer works, at least as of Snow Leopard, and the effect doesn't work with mineffect scale.)

To get your windows back in shape, minimize them again from the Windows menu.

AFAICT MacPilot doesn't list any hidden preferences for MS Office or Photoshop.

A, I guessed that, just saying I cant have a good feel of the joy of this feature until it find a hidden pref. for something I know or own.

Check this out. The program Secrets mentioned in the article can help. The article deals with hidden prefs of the applications.
http://www.macworld.com/article/139053/2009/02/safari4prefs.html

We've given you examples, for things you know and own. Dock, for example.

In my last post, I listed several preferences for Dock. If you go to System Preferences->Dock, you'll see some but not all of these options; the ones you don't see there are "hidden".

For example, System Preferences will let you set "Minimize windows using:" to "Genie Effect" or to "Scale Effect". The "Suck Effect" isn't listed, so it's a "hidden setting".

If the dock is narrower/shorter than whatever edge of the screen you put it on, it gets centered on that edge. But by setting the hidden preference "pinning" to "start" or "end", you can slide it along that edge to a corner. Center the dock again by setting "pinning" back to its default value of "middle".

When you select an app In MacPilot's left-hand pane you see a list of its hidden prefs in MP's right-hand pane.

There is no "feature [...] to see hidden prefs;" every pref that MP displays for any particular app is a hidden pref.

<clip>content removed<clip>

Ok guys, thanks...