I just looked at the files in /tmp, and noticed many files (quite a
lot!) which i would like to know about their future. will kde will
remove them automatically?? or I have to do?

also I noticed there were videos which corresponds to the dvd i watch
sometimes, I was surprised to seee them here; It seems linux is copying
any DVD i'm watchin onto the hard drive in /tmp!
is it normal??

heavytull wrote:
> I just looked at the files in /tmp, and noticed many files (quite a
> lot!) which i would like to know about their future. will kde will
> remove them automatically??

I doubt that KDE will ever remove the files in /tmp. That's not KDE's
job.

> or I have to do?

You'll have to. Or at least, you'll have to arrange for something to
delete the contents of /tmp on a regular basis.

> also I noticed there were videos which corresponds to the dvd i watch
> sometimes, I was surprised to seee them here; It seems linux is copying
> any DVD i'm watchin onto the hard drive in /tmp!
> is it normal??

It isn't "linux" copying those files, it is what ever tool you are
using to watch the DVDs with. Those files aren't "normal", but they are
hardly abnormal either.

You might want to put a command to clean out /tmp into your crontab
(/etc/cron.daily would be a good place). Such a command could look like

find /tmp -atime +3 -exec rm -f {} \;

which will clean out files that haven't been referenced in 3 or more
days

HTH
--
Lew Pitcher

Lew Pitcher wrote:
> You might want to put a command to clean out /tmp into your crontab
> (/etc/cron.daily would be a good place). Such a command could look like
>
> find /tmp -atime +3 -exec rm -f {} \;
>
> which will clean out files that haven't been referenced in 3 or more
> days

I would add the option(s) of "-type f" or "-type d" or "-type f -o -type d" to only remove files / directories / both. I had a similar cron job as above set to 90 days and it was amazing how much like clock work my MySQL server would fail to respond when it's socket was removed from /tmp. Just a heads up.



Grant. . . .

Le Sun, 23 Jul 2006 21:34:18 -0500, Taylor, Grant a écrit*:

> Lew Pitcher wrote:
>> You might want to put a command to clean out /tmp into your crontab
>> (/etc/cron.daily would be a good place). Such a command could look like
>>
>> find /tmp -atime +3 -exec rm -f {} \;
>>
>> which will clean out files that haven't been referenced in 3 or more
>> days
>
> I would add the option(s) of "-type f" or "-type d" or "-type f -o -type d" to only remove files / directories / both. I had a similar cron job as above set to 90 days and it was amazing how much like clock work my MySQL server would fail to respond when it's socket was removed from /tmp. Just a heads up.
>
>
>
> Grant. . . .

That'd be b0rken if your special file is in a directory :-)

# mkdir -p /tmp/Roll/Over/Lay
# mkfifo /tmp/Roll/Over/Beethoven
# touch /tmp/Roll/Over/Lay/Down
# tree /tmp/Roll
/tmp/Roll
`-- Over
|-- Beethoven
`-- Lay
`-- Down

Now, if you use :

# find /tmp/Roll/ \( -type f -o -type d \) -exec rm -rf {} \;

Your pipe goes down the drain, and if you try :

# find /tmp/Roll/ \( -type f -o -type d \) -exec rm {} \;

The dirs will rot forever :-)


I'd bet just serializing the rm's this way would be correct :

find /tmp/Roll/ -type f -exec rm {} \;
find /tmp/Roll/ -type d -exec rmdir {} \;

Or, for fun you'd like to use xargs and test if you need a rmdir or
a plain rm, but that'd be greediness ;-)


Ah, heatwave again ... Grzzzkbzzk---zhplop ;-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Loki Harfagr wrote:
[snip]
> I'd bet just serializing the rm's this way would be correct :
>
> find /tmp/Roll/ -type f -exec rm {} \;
> find /tmp/Roll/ -type d -exec rmdir {} \;

A word of caution to the OP: if you use the above examples to build a
cleanup script, you'll wind up cleaning out /everything/ in /tmp,
including the necessary KDE subdirectories (why KDE would require
/preallocated/ subdirectories in /tmp, I'll never understand). Further,
if you add in the "-atime +3" option (or similar), you'll find that the
"-type f" find will update the directory atime values, and the "-type d
-atime +3" test will never locate a directory that hasn't been accessed
in the last 3 days.

Really, if we are going to get this technical on a newbie, we probably
should just direct him to a proper /tmp cleaner, and let him install
/that/ instead.

- --
Lew Pitcher

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFExRnuagVFX4UWr64RApMFAJ9ELLwMqTRtDozmKNwlwb q2wQhkKgCeL8uB
3nM6+iQgnci2z2VP1fLs7cs=
=Uuwr
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2006-07-24, Lew Pitcher <lpitcher@sympatico.ca> wrote:
>> find /tmp/Roll/ -type f -exec rm {} \;
>> find /tmp/Roll/ -type d -exec rmdir {} \;
>
> A word of caution to the OP: if you use the above examples to build a
> cleanup script, you'll wind up cleaning out /everything/ in /tmp,

Yes, I noticed that right away too. Can't see how he didn't.

> Further,
> if you add in the "-atime +3" option (or similar), you'll find that the
> "-type f" find will update the directory atime values, and the "-type d
> -atime +3" test will never locate a directory that hasn't been accessed
> in the last 3 days.

True, but the following should work (untested)

# find /tmp/Roll/ -type f -atime +3 -exec rm {} \;
# find /tmp/Roll/ -type d -exec rmdir {} \;

Now any files that haven't been referenced in 3 days are deleted, and
any empty directories will be nixed as well.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFExSkyz8zcalmVmBkRAkcrAJ9b2zlDLV5xe115x5Tbud m5Qc18TgCeId6e
lU7rvmg+iw3PM/u1Tprr2kU=
=hPwP
-----END PGP SIGNATURE-----

+Alan Hicks+ <alan@lizella.network> trolled:

pgp trash troll delete

You would earn a lot more respect from the other posters if you
simply buried your pgp trash in the headers of your messages.

Why don't you do this? There is no reason not to do this, now is
there? Can you give us a reasonable reason why you don't bury your
pgp garbage in your message headers?

cordially, as always,

rm

+Alan Hicks+ wrote:
> True, but the following should work (untested)
>
> # find /tmp/Roll/ -type f -atime +3 -exec rm {} \;
> # find /tmp/Roll/ -type d -exec rmdir {} \;
>
> Now any files that haven't been referenced in 3 days are deleted, and
> any empty directories will be nixed as well.

I might suggest the addition of the "-p" (parent) switch to rmdir so you can clean out a directory structure that only contains directories and no files.



Grant. . . .

Le Mon, 24 Jul 2006 16:07:51 -0500, +Alan Hicks+ a écrit*:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2006-07-24, Lew Pitcher <lpitcher@sympatico.ca> wrote:
>>> find /tmp/Roll/ -type f -exec rm {} \; find /tmp/Roll/ -type d -exec
>>> rmdir {} \;
>>
>> A word of caution to the OP: if you use the above examples to build a
>> cleanup script, you'll wind up cleaning out /everything/ in /tmp,
>
> Yes, I noticed that right away too. Can't see how he didn't.

In case the "he" in "Can't see how *he* didn't." is supposed to be me
I can answer easily to the question :-)

A. The pair of expression quoted will *not* 'wind up everything'
it will leave alive every that's not a file or a dir and
it'll also let live any protected file and any dir that's not
empty. Which was exactly what I understood as requested, at least that's
really much less destructive than the previously suggested
'\( -type f -o -type d \) '. My addup was only about not
killing the 'special' files, like sockets or pipes.

B. Now I understand a big difference is that I didn't leave the
test on -atime +3, a bit on purpose too as I wouldn't use it.

1. my /tmp when mounted on real hard disks are mounted 'noatime'
this is just because I don't like to lose a few cycles of MTBF for the
sake of stamping files that are not supposed to last.
2. On most of my systems the /tmp is in RAM, this is much less
stress on the disks and the extra bonus is that next boot or init cycle
you won't have to launch a `find` to cleanse it :-)


As for the excellent question (Lew,why KDE would require
/preallocated/ subdirectories in /tmp, I'll never understand) I plentily
agree !
Any piece of soft that requires something in the *temporary* space
to be assumed as "immortal" is Redmondfinkking compatible and should be
ignored or thrashed (note, I also put my /Trash in RAM, much quicker ;-)
Besides, everytime some stuff from KDE gets stuck my quickest patch to it
is to remove all the /tmp.


>> Further,
>> if you add in the "-atime +3" option (or similar), you'll find that the
>> "-type f" find will update the directory atime values, and the "-type d
>> -atime +3" test will never locate a directory that hasn't been accessed
>> in the last 3 days.
>
> True, but the following should work (untested)
>
> # find /tmp/Roll/ -type f -atime +3 -exec rm {} \; # find /tmp/Roll/
> -type d -exec rmdir {} \;
>
> Now any files that haven't been referenced in 3 days are deleted, and any
> empty directories will be nixed as well.

Agreed, if you really want to keep stuff on the /tmp that's be better
though, as I wrote before I'd mount the /tmp 'noatime' then it'd be
better to use -mtime in the find expression.

Afterall that's Archimedes principle that "every file dropped in the
bucket three days ago and that didn't surfaced would be seen as drowned,
trespassers will be shot" :-)

* Taylor, Grant <gtaylor@riverviewtech.net>:
[ ... ]
> I might suggest the addition of the "-p" (parent) switch to rmdir so
> you can clean out a directory structure that only contains directories
> and no files.

Using the `-depth' option with find should achieve the same thing as
well as the using the `-empty' test may also be safer. One find
invocation can be used to clean out files and directories, in fact.

# find /tmp -depth -atime +3 -type f -o \( -empty -type d \) -delete

The `-delete' action has been around long enough to work with versions
of find going back a few Slackware releases and saves calling another
program.

--
James Michael Fultz <xyzzy@sent.as.invalid>
Remove this part when replying ^^^^^^^^