bug with os.rename in 2.4.1?
nick at craig-wood.com
Thu Apr 30 10:30:04 CEST 2009
Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 28 Apr 2009 14:30:02 -0500, Nick Craig-Wood wrote:
> > t123 <tom.lukes at gmail.com> wrote:
> >> It's running on solaris 9. Here is some of the code. It's actually
> >> at the beginning of the job. The files are ftp'd over. The first
> >> thing that happens is that the files get renamed before any processing
> >> of the file. And when it fails, it always fails at the first file,
> >> comm.dat. What I can't understand is why the inconsistent behavior.
> >> try:
> >> if os.path.exists(paths.xferin_dir+'/COMM.DAT'):
> >> os.rename(paths.xferin_dir+'/COMM.DAT',paths.xferin_dir+'/
> > This code is inherently racy... What if two copies of your code started
> > simultaneously? They might both run the os.path.exists but only one
> > will succeed in the os.rename.
> > You could write instead
> > try:
> > os.rename(paths.xferin_dir+'/COMM.DAT',paths.xferin_dir+'/
> > except OSError:
> > pass
> > Which isn't racy.
> The race condition is still there. The only difference is that in the
> first case it fails noisily, with an exception, and in the second it
> fails quietly and does nothing.
I'd argue that since os.rename implements the syscall rename() and
that is defined to be atomic (give or take) then the above is atomic
and can't possibly be racy.
Wikipedia's definition :-
A race condition or race hazard is a flaw in a system or process
whereby the output and/or result of the process is unexpectedly and
critically dependent on the sequence or timing of other events. The
term originates with the idea of two signals racing each other to
influence the output first.
The original example was clearly racy.
I guess using the wikipedia definition, the fact that I've caught the
exception makes it no longer unexpected and hence no longer racy.
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick
More information about the Python-list