Here is a temp fs line from fstab.

Some music recording programs work better with it, I don't know how it is used though.

Usually amongst the top 3 lines, / , /boot, swap (maybe) then...

tmpfs /dev/shm tmpfs defaults 0 0

Confirming Mandriva connection.

regards, Glenn

Nice. Did you try exorcism and voodoo yet ?

Now really, that behaviour is weird. Did you search the entire system for further instances of tmpwatch (not that there is an other copy in /bin or /sbin...)? Sorry, I just can't think of anything else.

Now that you mentioned it, I ran find / | grep tmpwatch. I didn't find another instance or binary of tmpwatch, BUT I found something that solved the problem.

This search came up with a file called /etc/sysconfig/tmpwatch, which upon opening revealed the following lines:

I edited it to add /tmp/* and /home/username/tmp/*, like this:

After more than 1 hour, my files in the tmp folders remain!

Now, it would be really interesting to know WHAT service it actually was, still deleting my files (considering that I already removed the actual tmpwatch binary from /usr/sbin). But for the actual problem - it is solved now.

Thanks to everyone for help! If you find out this mysterious file deleting service of Mandriva, please drop me a message. Just for curiosity.

That would've been my next, locical step.

Hmm. I was quite sure you had looked, but sometimes I do overlook the obvious, so I asked...

If the system loads tmpwatch during startup, renaming or deleting the binary won't have any effect. Did you boot after renaming or deleting the culprit? Because it must be the cause, it simply would not make any sense at all that changing /etc/sysconfig/tmpwatch would halt a differently named program.

Btw: Glad you got rid of that pest .

I did ps aux | grep tmpwatch before deleting the binary. It was not running. But I cannot reboot the PC, as it's a production server.

Maybe some other service has wrapped tmpwatch into its use, causing it not to show up with ps? Obviously, the problem was caused by tmpwatch somehow, as the exclusion list fixed it.

Or tmpwatch calls something else and exits. At least it must reload its configuration. Oh well, since the exclusion works -- btw. is tmpwatch a script? Maybe you can look into it and see what it does.

Seems to be a binary. To me it seems that it is not something left running in the background, but rather something that the system runs periodically (even though I was unable to find it from crontab with its own name). That's why changing the configuration has an immediate effect.

If deleting the binary led to no consequence, this is what I think happened:
— The tmpwatch binary is loaded and run at startup as a kind of daemon, not as a cron job, else later calls would have failed.
— This binary is notified of configuration changes by inotify, or it periodically looks at the configutation file's timestamp.

In Linux/Unix, file descriptors are associated with the file inodes, not file names. A single inode may have any number of names (using hard links). Besides, opening an inode is like creating a temporary new name which resides in memory.
The rm command does two things:
— delete the given name;
— if that name was the last, also delete the inode (sort of…).

In your case, you probably deleted the last filesystem inode, but one probably remained in memory, thus enabling the continued use of the program until its exit.

Yves.

That's a good response, I wonder how this "for want of a better word- error" was created to begin with.

I've never had such a problem,

I have often relied on a package (sorting deps) when configuring, that can't be found or installed with out removing the last weeks worth of updates. Or relied on a package linking correctly with the newly installed....

But that's me, I configure till .. re-install.

Regards, Glenn