On Mon, 2 Dec 2002, Tim Sweetman wrote: > 1. Its temporary filename doesn't incorporate anything random, or the > process ID. So should you happen to have two processes running > simultaneously (eg. wraparound cron syndrome), you could end up end with > interleaved interleaved content and not be very content content. Innit.
Yes, this is true. Don't do that. Or use some external locking method. ;-) Currently IO::AtomicFile is one step up from the basic IO::File. It is what it is. Actually I was thinking of writing some patches to IO::AtomicFile to turn on the options of a) Optionally locating the temp file in another dir on the same filesystem b) Allowing random filenames as temp files, thus avoiding the need to lock I've already done some work on this, but then I got really busy writing the actual calendar. As I said on IRC just now, I'll do more on it after the 25th. The actual patches aren't hard, it's writing the interface, getting the documentation and tests together that are causing the problems. > If you don't explicitly do the "disaster recovery" bit by using an eval > block and the ->delete method .... Admittedly this makes life easier for > people .... who don't want to write "->commit", but that strikes me as > the Wrong design decision. I like the way it works. It doesn't get in the way when I'm working, I just use it as normal. When something goes wrong - when there's an Exception, this is the exceptional case. I like having separate error handling code. Most of my code looks like this my $fh = IO::AtomicFile->new("foo",">") or die "Can't open 'foo': $!"; eval { print {$fh} $self->bar(); print {$fh} $self->baz(); print {$fh} $self->buzz(); close $fh; }; if ($@) { $fh->delete; ... other error handling code ... } (obviously bar, baz and buzz throw exceptions if there's any problems) What you're suggesting is something like my $fh = IO::AtomicFile->new("foo",">") or die "Can't open 'foo': $!"; eval { print {$fh} $self->bar(); print {$fh} $self->baz(); print {$fh} $self->buzz(); $fh->commit; close $fh; }; if ($@) { ... other error handling code ... } I can see how that would work. If I was the author I'd probably either put it as an option in the constructor, or write a subclass IO::AtomicFile::Explict that only moved when you called commit. Maybe you should email the author ([EMAIL PROTECTED]) with these suggestions, or one of us could whap them into rt. Later. Mark. -- Mark Fowler http://www.twoshortplanks.com/ The 2002 Perl Advent Calendar [EMAIL PROTECTED] http://www.perladvent.org/2002/ a different perl module featured every day