3/7 Note to self: Debian cleans out /var/run on reboot. This is a bad
thing if you place Cyrus imapd's config directory under /var/run.
\_ linux = sux0rz!
\_ heh, it also cleans out /tmp -- which sucks when you work on
some stuff on there, and then you kill your system =[
\_ you should never work on anything important in /tmp as
many systems use a memory fs for /tmp which will always
be cleared on reboot.
\_ yea... I know, bad habit... but speaking of tmp...
screwdriver: /var/tmp -> /tmp
Don't important things like editor recovery files end up
in /var/tmp?
\_ noone ever said screwdriver was run well.
\_ Seeing as I was bit on the ass on /var/run, it would
be unfair of me to think you foolish for making the
same mistake with /tmp, but I kind of took /tmp not
being preserved across reboots for granted. And to
whoever asked if editor recovery files end up in
/var/tmp, you shouldn't need editor recovery files
after a clean reboot. Do you think it is reasonable
\_ Um.. Multiuser system, anyone?
\_ Um, if you leave your *unsaved* edits to your PhD
thesis open for hours at a time on a system that
someone else may remotely reboot, you get what you
deserve. -op
to expect editor recovery files to *reliably* survive
a catastrophic system crash? If you think it is
reasonable, could you kindly explain how it is
possible, and cite an example of an OS that does
this? -op
\_ Yeah, put the editor recovery files in each user's
home directory. It's not rocket science.
\_ This will not preserve the files in the event of a
catastrophic system crash. Modern filesystems
buffer writes in memory for performance. -dans
\_ If you're going to play *that* game then no
modern OS is 'safe'.
\_ Yes it is reasonable and most OSes do this. Examples
are Linux, HP-UX, and Solaris.
\_ the whole *point* of editor recovery files is to
recover work lost in a catastrophic system crash. -tom
\_ Someone take root away from the OP immediately!
\_ no, learning by screwing up is the best way. im
certain op will never make that or similar
mistakes on any OS again.
\_ Actually, no tom. The whole point of editor
recovery files is to recover work lost in a
catastrophic *editor* crash. In a catastrophic
system crash, you cannot *reliably* reconstruct the
state before the crash so you cannot *reliably*
recover. In order for an editor to be able to
reliably recover from a catastrophic system crash,
it would need to write its recovery log to an
ACID-compliant store. I am not aware of any editor
that does this, nor am I aware of any widely
available OS that features an ACID compliant
filesystem. Perhaps veritas makes something like
this, but such a filesystem would be of limited use
since its performance would be awful. -op
\_ are you a complete moron? /var/tmp has been
around for longer than ACID or Veritas have been.
It's not meant to be some kind of bank transaction
rollback log, it's meant to be "oh shit, I was
working on something important, can I recover
any of it?" -tom
\_ not on debian! hah! Sorry op. |