ACL problem on Preferences causes Dashboard widget problem

Just spent 3 hours working out what a problem was with my MacBook. Often I find problems 'stack' on top of each other. To fix A, I need to fix B, but to fix B I need to fix C. you can imagine the stack grows high! So I started with excessive fan on my MacBook and (so far) I'm at an ACL issue with Preferences causing none of my apps being able to write preferences - including the ubiquitous command 'defaults' that is used in so much of the posts on Dashboard. 


The fan noise problem I traced using Activity Monitor. Start it up (command space to get to spotlight) by typing Activity Monitor into spotlight. then order by Process and choose My Processes. The one at the top is the one sucking most CPU. as seen in other posts, my safari was big and so was my sync server. 


To fix safari I went to the safari menu and chose empty cache. This certainly sped it up. Safari had been slow. Clearing the cache fixed this, and it went faster. it's CPU usage went down.


Then to sync server. This post on resetting sync contained some truths about resetting the thing. It seemed to get the CPU usage down once I had done the reset of all the sync databases. but there sstill seemed to be occasional spikes that seemed excessive. It turned out whenever i started iCal it went nuts and hung up almost syncing ONE of my calendars. I found in a number of posts the idea that you should export your calendars and then delete them so that any corruptions could be fixed. I wasted a couple of comical hours with me deleting them, and then they reappearing. I had forgotten that sync was of course retrieving them from mobileme and writing them back to my machine. But at least they weren't corrupted now. Anyway that seems to have sorted sync server.


I have a dashboard widget called iStatPro that I LOVE. It shows CPU, fan speed and CPU heat, and does history. This was a good debugging aid during the whole process. I moved it around and tried to delete some of the other widgets I have on my dashboard. But each time I logged back in the deleted widgets were there again. 


I found posts talking about resetting dashboard. I did the killall Dock and tried to do defaults write com.apple.dashboard. BUT I got an error about permission denied. 



machine:Library userx$ defaults write com.apple.dashboard devmode NO
2010-01-02 14:19:56.476 defaults[972:10b] Could not write domain com.apple.dashboard; exiting

I couldn't work out why. I thought maybe the file has permissions that prevent it. So I deleted the file and hoped that osx would rewrite the file. It started up but didn't rewrite the file. Strange. I then did some command line stuff to work on it more:


ls -ld ~/Library/Preferences 



machine-3:Library userx$ ls -ld ~/Library/Preferences
drwx------+ 332 userx  staff  11288 31 Dec 20:17 /Users/userx/Library/Preferences

showed that there was a + right at the end of the permissions block in the line. This means there is 'other security information' (see man ls). But what is it? This is very hard to find (or I spent too much time on it). I found that the + is either extended attributes or an access control list.  from the man ls:



If the file or directory has extended
     attributes, the permissions field printed by the -l option is followed by
     a '@' character.  Otherwise, if the file or directory has extended secu-
     rity information, the permissions field printed by the -l option is fol-
     lowed by a '+' character.

So, to find out how to see these/ manipulate these, lots of googling, man's etc and you can do: 
the manual entry for man ls shows that you can do ls -@. No - only if you do ls -@l can you see the extended attributes. ALSO if you want to see the directory entry you have to append d:



machine-3:~ userx$ ls -@ld Dropbox
drwxr-xr-x@ 8 userx  staff  272 29 Dec 21:05 Dropbox
com.apple.FinderInfo 32 

That's great but doesn't help. So then you can use ls to get the ACL:

machine-3:Library userx$ ls -led ~/Library/Preferences

drwx------+ 332 userx  staff  11288 31 Dec 20:17 /Users/userx/Library/Preferences

 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

ok THAT does not look right. What this is saying is that NOBODY should be able to add files in there NOR should they be able to delete, add sub dirs etc. So, I looked at another users's directory to see what their ACL said: 

machine-3:~ usery$ ls -eld ~/Library/Preferences

drwx------+ 37 usery  staff  1258 Jan  2 14:41 /Users/usery/Library/Preferences

 0: group:everyone deny delete

Soo - that's intriguing. how mine go so far wrong I have no idea. the command line to fix it was typical un*x obscurity:

machine-3:Library userx$ chmod -a# 0 ~/Library/Preferences

machine-3:Library userx$ chmod +a "everyone deny delete"

NICE. beautiful command line design. You can see that ACL support was hacked into unix can't you. I think it originally came from DEC and the VMS? not sure. anyway it makes sense to put it in chmod (sort of). but a chacl would be better... 

then to have -a# 0 mean delete the entry number 0 is beyond me. 

but that's because +a means add an entry. plus minus get it? 

anyways. that reset the ACL and now I can write. I did 

touch ~/Library/Preferences/blah

and that proved the problem was fixed. 

the ACL thing was just so bizarre I was compelled to make an annual entry in my blog ;-)