1 |
On 16/12/2014 02:17, walt wrote: |
2 |
> I confess I've never thought much about why /tmp exists, but today I was |
3 |
> inconvenienced when an end-user utility (uudeview) ran out of space on /tmp |
4 |
> while doing an ordinary end-user task processing very large end-user files. |
5 |
> |
6 |
> Why is an end-user program using a "system" directory like /tmp in the first |
7 |
> place? |
8 |
> |
9 |
> I suspect that the need for /tmp is now gone, but I'm prepared to be wrong :) |
10 |
> |
11 |
> |
12 |
> |
13 |
|
14 |
|
15 |
/tmp was always intended to be used exactly the way you are using it: |
16 |
|
17 |
yes, it is a "system directory" because it's located in / but you have |
18 |
permissions to use it. The mode is 1777 so everyone can |
19 |
read/write/execute the contents but it's also sticky (the 1) so only you |
20 |
can delete what you put there. It's a general-use scratch pad area that |
21 |
everyone can use safely, unfortunately in these days of huge cheap disks |
22 |
some apps abuse it by writing gigantic files there and you run out of space. |
23 |
|
24 |
How have you set /tmp up? Is it on-disk or a tmpfs? You migght need to |
25 |
make it bigger. |
26 |
|
27 |
/tmp is still very much in use and very much needed, it isn't going |
28 |
anywhere soon. The FHS has something interesting to say about /tmp, |
29 |
along the lines of: |
30 |
|
31 |
"A general use scratch pad area where files written are not expected to |
32 |
survive successive invocations of the program that wrote them". That's |
33 |
interesting as it means the sysadmin can delete everything in /tmp at |
34 |
any time for any reason, and all apps will continue to work just fine as |
35 |
if they had not been deleted at all :-) |
36 |
|
37 |
|
38 |
|
39 |
|
40 |
-- |
41 |
Alan McKinnon |
42 |
alan.mckinnon@×××××.com |