Nigel Garvey stated that the temporary items path from user domain doesn’t get deleted when you restart your machine.
Not that that happens that often.
Well, I figured for awhile that using path to temporary items to store data, would be more secure than using the temporary items folder from local domain. I think that is not the case for reasons I shall not delve into.
However:
Path to temporary items from user domain, is a great place for scripters to store their scratchpad, and snippets that are going to be tossed, or should be tossed anyway. It makes the Desktop to a much nicer place. I have dragged the folder up onto the side bar of Finder for easy access.
This snippet trashes the contents of the local temp folder:
tell application "Finder"
move every item of folder ((path to temporary items from user domain) as text) to trash
end tell
And this opens it.
tell application "Finder"
open (path to temporary items from user domain)
end tell
Edit:
I have also made an alias to the temporary items folder into my home folder, so it is easily cd’d into from a Terminal window.
The actual reason for temporary items in user domain is exactly as you describe in your first line but not security. User domain cache/temporary items are persistent even after a reboot, BSD temporary items are not. Apple couldn’t just say we make that data persistent because many, i mean many, software relies on this still today. Because Apple still prefers to use the /private/var/folders directory as their temporary items in their software so I’m not convinced to use it myself.
If you need persistence use user domain, otherwise use system or local domain.
The whole idea, was not persistence, but having a well defined place to litter, when say I experiment with stuff. So, when Mac Os X doesn1t wipe out the path to temporary items from user domain, I’ll say that is a feature!
The whole idea behind /tmp, was from an era of time where disk access where way slower than now, so when you wrote to /tmp, you could just forget about deleting it, knowing that the system took care of it. And I think, at least it was that way, that every process could read and write to /tmp. Later on, you could just read and write to your own /tmp files.
My initial point was to use the path to temporary items as a “safer” tmp. But the thing is, if someone is able to read from path to temporary items from local domain, then they should be equally capable of reading to path to temporary items from user domain. (Maybe I have got this wrong.) And this is of course of less interest if the path to temporary items from user domain isn’t emptied automagically.
Then I got the idea of using it for my own benefit, a dedicated place to litter with temp files, which this post was all about really.
I realized that noone but me seemingly uses the path to temporary items from user domain (on my machine), so that is a nice place. It is also an advantage, that the temp area is persistent until I trash it!
It resides under caches, which is a great place to store more persistent data. Like script properties intended to be persistent. I store my temporary script properties in the temporary items folder, I will change those to be stored in the temporary folder of local domain, so they get removed.
Here is a script that reveals the Info.plist files of preference panes, so you can go in and find the unlocalized anchors, in order to minimize UI scripting.
property tlvl : me
script revealPrefPanes
local prefName, prefPath, chosenPrefPane, i, prefpaneItem
tell application "System Events"
set {prefName, prefPath} to {name, path} of every disk item of folder ((name of startup disk & ":System:Library:Preferencepanes:"))
end tell
set chosenPrefPane to choose from list prefName default items item 1 of prefName with prompt "What Preference pane to dig into?"
if class of chosenPrefPane is boolean and chosenPrefPane is false then
else
set i to tlvl's indexOfItem(chosenPrefPane, prefName)
set prefpaneItem to item i of prefPath & "Contents:Info.plist"
tell application "Finder" to reveal prefpaneItem as alias
end if
end script
tell revealPrefPanes to run
on indexOfItem(theItem, itemsList) -- credit to Emmanuel Levy
local rs
set text item delimiters to return
set itemsList to return & itemsList & return
set text item delimiters to {""}
try
set rs to -1 + (count (paragraphs of (text 1 thru (offset of (return & theItem & return) in itemsList) of itemsList)))
on error
return 0
end try
rs
end indexOfItem
set systemPreferencePanes to path to system preferences
tell application "System Events"
set {prefName, prefPath} to {name, path} of every disk item of systemPreferencePanes
end tell
You can check the class or the value, but both is redundant
It was more about littering, than about path to temporary items, you know . free associations.
Seriously, I didn’t want to put it into a topic, its . a minor detail of no great relevance for that many people. But useful for some, or for those that need it, should it come to it.
Well it’s obvious you enjoy posting to this site. Please try to keep it tidy. It’s meant to be a nice friendly place to “hang out”, but it’s primarily intended as a resource for scripters. So ” as with most fora ” it’s vital that threads remain roughly on-topic to avoid confusion and time-wasting for those seeking enlightenment. If you have a script to post which has nothing at all to do with the subject under discussion (or with any relevant side-issues), start a new thread for it. If you don’t think it’s interesting enough for that, don’t post it!
That story would be a good candidate for an urban legend. The performance gains they did in the old days was mounting a separate disk into /tmp so that the main disk’s head movement won’t be interrupted by reading temporary data. Of course, partitioning didn’t do the trick, the disk needed to be physically two disks. Machines with a separate /tmp disk couldn’t rely on persistence because the disk should and could be changed between two boots of the OS. The actual reason why no data can be persistent in /tmp.
Today (since I first met Darwin;Mac OS X 10.2):
Nowadays there is no difference between /tmp and /private/tmp and has 777 privileges which means almost the same as ‘no privielges at all’. The problem still is multiuser usage, when fast user switching is available you could having problems if user A and user B are running the same process. The problems kicks in as soon as you’re using a desktop like Mac OS X that sits on top of Unix.
An (silly) example: When I develop an web browser and store my temporary internet files (with cookies included) in the /tmp folder I would have problems with machines with fast user switching enabled. User A and user B would use the same cookies; user A logins in to his mail using web mail and after that he logged in user B goes to the the same web mail and he is immediately logged into the user A’s mail account. Of course in most situations a privilege error will occur but you can see a worse scenario could happen if it doesn’t.
You can see that the problems kicks in with multi user desktops and therefore Mac OS X should have from the start using different temporary folders which will be created as soon as a user logs in to Mac OS X. This is created in /var/folders///-TMP-/ for each user that is logged into Mac OS X. That also means that even if you ask temporary items from system domain you will get a path that is specific for the current user.
A folder with persistence or no persistence is of course a feature both ways. I’m not saying that any one of those is worse or better I’m just saying that the argumentation for one to use (safety and performance) are both wrong.
That was the rationale for thinking that the tmp folder in user domain is not securer than the one in local domain.
I am rusty about the setuid and guid bits on those tmp files, and how they affect the reading and writing privileges.
I just bluntly figured that the user domain is a good place to store my own temporary items. (script, shell script snippets, test files and such). I have actually having missed that for a long long time, and found the perfect spot, since I saw no security gains in using the user domain tmp for regular temporary items. And I can trash it at will!
For the record. I started up and installed my three weeks old MBP (Mountain Lion) and I see that there is still a temporary item folder is created for every user in /var/folders but only the temporary folder is now named ‘T’ and no longer ‘-TMP-’. I never understood why Apple chose the name starting with a hyphen but maybe to open the folder more difficult (by default the shell returns an error).
Now, that is a possibilty, although not deterring for people that have come around that far from the outside.
The whole reason for me starting to reasoning over this, tmp, and such, is of course for the keychain kits out there now, that makes it easy for anybody to suck up a keychain from a user that logs on with key chain access.
I don’t use fast user switching for the same reason, as it at least was a loop hole there. I also use separate accounts for administrating my mac.
do shell script with adminstrator privileges works great, when I am need to “sudo” something.
That’s not possible. Like I said, since the first release of Mac OS X, or at least since fast user switching, the /tmp folder isn’t used for desktop users (BSD-level only). The actual folder is now stored in ‘/var/folders/xx/xx/T/’ (T=-TMP- on older systems) what means that per console user (as apple prefer to name the desktop user) has it’s own TMP folder and therefore ‘path to temporary items’ is also a personal path rather than an system path.
Second: Obtaining the keychain is easy with root access, but the information itself is still useless because you’re missing some keys to decrypt.
But when I make temp files and such by mktmp? then those are created, not in the /tmp folder, but in the folder you mentioned the first time, so I was aware of this really. That /tmp has never been used on Mac Os X, I just used it as a synonym, not having to type /var/private/tmp. ( I believe that is the path in Snow Leopard, and funny that they changed it. But they have changed some stuff with the launch services as well. But all in all, the most sexy system on the planet! )
Can we clean this thread up ?!? Is there an unScripted article detailing temporary items or an Apple support doc? I think it would be helpful to post ONE summary about the locations mentioned in the thread.
