bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mv -f may remove the destination file


From: Bob Proulx
Subject: Re: mv -f may remove the destination file
Date: Thu, 5 May 2005 23:59:50 -0600
User-agent: Mutt/1.5.9i

Paul Eggert wrote:
> Urs Thuermann <address@hidden> writes:
> > lstat64("bar", 0xbffff904)          = -1 ENOENT (No such file or directory)
> > rename("foo", "bar")                = 0
> 
> > This check, however, is not sufficient as a file named bar could be
> > created between the calls to lstat(2) and rename(2).
> 
> In general, mv is not (and is not supposed to be) immune to race
> conditions like that.  If two processes are futzing around in the same
> directory, bad things normally can happen with the standard utilities.
> There are some exceptions, but this isn't one of them.

Agreed.  But I think the reason for the question might be for what
purpose is the lstat() call there?  It is there to tell if the
destination is a directory and if so then it converts the rename to a
rename to a file in the subdirectory, also as required by POSIX.

With the -f the code does not need to care if the target is writable
or not but regardless it needs to know if it is a directory or not.  I
don't think it is possible to avoid using multiple system calls and
still have correct 'mv' behavior and so it is not possible to avoid
the race either.  The rename(2) call will not automatically handle
directories as destinations, but 'mv' must.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]