Re^3: opening files: link checking and race conditions

okay but if that is a problem too, doesn't this fix both?

my $lflag = ( -l 'foo' ); # check before opening
$lflag or open my $fh, ">>foo" or ErrorHandler( $?, $! );
$lflag = ( -l 'foo' ); # and again after opening
unless( $lflag } {
    # process file
}
$lflag or close $fh;
[download]

One world, one people

Comment on Re^3: opening files: link checking and race conditions Download Code

Replies are listed 'Best First'.
Re^4: opening files: link checking and race conditions by Joost (Canon) on Aug 03, 2005 at 13:32 UTC
No, the whole point is that you can't guarantee that the thing the filename "foo" points to doesn't change between operations. You're only making it harder, not impossible, to mess with foo. update see Re: opening files: link checking and race conditions for code that can cause your method to fail, and Re^2: opening files: link checking and race conditions for the best solution (even if it's not 100% portable) "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^4: opening files: link checking and race conditions by danderson (Beadle) on Aug 03, 2005 at 22:55 UTC
Google "atomicity" and "race case" for more information, but here's a brief way how that would die: (P1 is process 1, P2 is process 2, they're not actually in the same program, but the commands from each are interleaved here since that can happen in reality) `P1: my $lflag = ( -l 'foo' ); # seems good P2: makes foo a link - uh oh! P1: $lflag or open my $fh, ">>foo"; # does it fine, since $lflag was s +et before P2: remove that link, lickity-split! P1: $lflag = ( -l 'foo' ); # whups, everything seems ok...` [download] Make sense? Dave_the_m's code will exactly perform the actions for P2, btw. (Eimi's earlier explanation did exactly what your code does, too - look it over, the -l check happens before and after.)	[reply] [d/l]