Michael Stone wrote: > ...but without knowing what the end result is, I didn't see it as an > improvement. That is, if two processes are writing at the same time, > one's output is going to get clobbered--if one gets clobbered atomically > I don't see an obvious advantage.
Sometimes it does not matter which file is in place as long as the file in place is always syntactically correct. But you are right, not knowing the particular case here makes it hard to suggest an alternative. I was transferring from cases I have typically run into in my own experience and was pursuing an alternative which avoided spurious noise from commands. However, that noise may have been an early warning indicator that something was generally wrong. So making it quiet may not be a good thing after all because it removes the early warning of other problems. > Bob Proulx wrote: > > unlink($conf::build_dir/current-$main::distribution); > > symlink($main::pkg_logfile,$conf::build_dir/current-$main::distribution.$$) > > or die; > > rename($conf::build_dir/current-$main::distribution.$$,$conf::build_dir/current-$main::distribution) > > or die; > It's also not necessary to do the unlink in that case--actually it's > better not to, since the rename will clobber the destination anyway. Drat! You are correct. My test script had it right, unlinking the symlink target. But I goofed translating that to the *real* case and unlinked the wrong target. That should have been: unlink($conf::build_dir/current-$main::distribution.$$); symlink($main::pkg_logfile,$conf::build_dir/current-$main::distribution.$$) or die; rename($conf::build_dir/current-$main::distribution.$$,$conf::build_dir/current-$main::distribution) or die; With an unlink of the symlink target. Otherwise the symlink call may fail if it tries to symlink to an existing target. > I'd also use a better random filename than $$. That would be fine. But this is a temporary file being used by cooperating processes in a local tmp directory. It does not need to be random. It just needs to be unique among all of the processes at that moment in time. I don't think extreme measures are needed for this type of simple case. But obviously it won't hurt and if the case becomes more complicated later then the infrastructure is in place for it. But I was trying to keep the example simple. (And as you saw I still made a typo. :-) Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
