i'm just asking myself wether perl's "rename"-function is atomic.

what i mean is the following:

if i update a file 'orig.txt', say i append some lines to it, i'm used
to first copy this file to a temporary file 'tmp.txt', then append the
lines to 'tmp.txt', then use the following perl-code

rename 'tmp.txt','orig.txt';

i do this in order to increase security. if the program or the
computer crashes
while writing, the original file is not lost.

but what if it crashes during 'rename'?

is 'rename' atomic in the sense that it is either carried out
completely or not all all?

[...]

Anno> [...]

"yes" ... provided that you have rename(2).  If rename(2) is absent,
and being emulated using link(2) and unlink(2), there's a crash point
that would leave the file hardlinked under both the old and new names.

But (nearly?) all modern Unix flavors (since 2.8BSD and SysV and all
derivatives and copycats) have rename(2).

On a conventional Unix filesystem, I think rename must be implemented
by creating the new link, then removing the old link.  The difference
between this and an explicit link()/unlink() is that the system never
returns control to user space until the rename() operation is
finished.  But if the system crashes after the link operation but
before the unlink, then when you boot it back up again, you'll see the
file in both places.

In particular, I don't think rename() is usually guaranteed to be a
transaction in the database sense: If a database crashes in the middle
of a transaction, then when you bring it back up again, the
transaction will be completely undone.  I don't think rename() usually
has this property.  Systems with journalling filesystems may be able
to do this, but I don't believe it's universal.