is rename atomic? 
Author Message
 is rename atomic?

hello everybody,

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?

greeting from germany,
joachim



Sun, 16 May 2004 11:47:33 GMT  
 is rename atomic?

[...]

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

Yes.

Anno



Sun, 16 May 2004 12:28:09 GMT  
 is rename atomic?


Anno> [...]

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

Anno> Yes.

"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).

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Sun, 16 May 2004 15:48:06 GMT  
 is rename atomic?


Quote:


>Anno> [...]

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

>Anno> Yes.

>"yes" ... provided that you have rename(2).  

Are you sure that's true?  Rename is guaranteed to be atomic in the
couirse of normal operations, but that's only because the system can
guarantee that no other process gets a chance to execute until the
rename() operation has been completed.  If there's a system crash
partway through the execution of the rename(), you might get a chance
to see the filesystem caught in an inconsistent state.

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.

rd
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print



Mon, 17 May 2004 17:32:51 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. All computers in world MUST sync with ATOMIC clock before 12:00 AM 21July 2001

2. renaming file problem (rename / mv)

3. Is rename() atomic? And how do I parse a mail spool file?

4. I want to write to a file as an atomic transaction from perl

5. Atomic named pipe print?

6. atomic clock server access from Perl?

7. Atomic operations in Perl

8. Atomic Transactions on Files

9. perl dbm access atomic?

10. atomic file create (portable) in perl4?

11. atomic version of File::Transaction

12. DBI::ODBC MSSQL transactions not atomic?

 

 
Powered by phpBB® Forum Software