Is the shell command "mv" atomic

Is the shell command "mv" atomic

Post by RC Bry » Fri, 04 Apr 2003 06:15:06



I am writing a ksh script that allows multiple users to access a
resource and I was wondering if the mv command can be considered
atomic.  If two users run my script at exactly the same time, can I
safely assume that the one that does the first mv request will get the
file?  I was thinking and if I am not mistaken, the way mv works is to
1. Create a link to the file,
2. delete the old link to the file.

If two copies of mv are running simultaneously,
1. The first copy will create his new link to the file,
2. The second will create his new link to the file
3. The first copy will delete the old link to the file
4. The second copy will try to delete the old link that is not there
anymore.

I guess that mv will return a non-zero return code if it goes to
delete a link that is not there but this scenario will still result in
two links to the same file.

Comment anybody?

Thanks,
/RC Bryan

 
 
 

Is the shell command "mv" atomic

Post by Fletcher Glen » Fri, 04 Apr 2003 06:20:38



> I am writing a ksh script that allows multiple users to access a
> resource and I was wondering if the mv command can be considered
> atomic.  If two users run my script at exactly the same time, can I
> safely assume that the one that does the first mv request will get the
> file?  I was thinking and if I am not mistaken, the way mv works is to
> 1. Create a link to the file,
> 2. delete the old link to the file.

> If two copies of mv are running simultaneously,
> 1. The first copy will create his new link to the file,
> 2. The second will create his new link to the file
> 3. The first copy will delete the old link to the file
> 4. The second copy will try to delete the old link that is not there
> anymore.

> I guess that mv will return a non-zero return code if it goes to
> delete a link that is not there but this scenario will still result in
> two links to the same file.

> Comment anybody?

> Thanks,
> /RC Bryan

Don't forget that mv, when applied across a file system
boundary, will devolve to a cp followed by an rm.  The
exposure there is however long that the cp takes.

--
                Fletcher Glenn


 
 
 

Is the shell command "mv" atomic

Post by Andy Isaacs » Fri, 04 Apr 2003 06:30:45




>I am writing a ksh script that allows multiple users to access a
>resource and I was wondering if the mv command can be considered
>atomic.  If two users run my script at exactly the same time, can I
>safely assume that the one that does the first mv request will get the
>file?  I was thinking and if I am not mistaken, the way mv works is to
>1. Create a link to the file,
>2. delete the old link to the file.

>If two copies of mv are running simultaneously,
>1. The first copy will create his new link to the file,
>2. The second will create his new link to the file
>3. The first copy will delete the old link to the file
>4. The second copy will try to delete the old link that is not there
>anymore.

>I guess that mv will return a non-zero return code if it goes to
>delete a link that is not there but this scenario will still result in
>two links to the same file.

Preface:  I assume you are only using mv(1) to rename files or
directories in a single filesystem.  Cross-filesystem, mv functions
differently.

mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
the race condition you describe cannot occur.  Your script is safe.

-andy

 
 
 

Is the shell command "mv" atomic

Post by Chris Lowt » Fri, 04 Apr 2003 23:13:38



> mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
> the race condition you describe cannot occur.  Your script is safe.

No: Not true for all Unixes - some have "rename" as a system, and for others
"rename" is library call that uses link and unlink to do it's work.

Under linux (for example) - "rename" is indeed a system call - but I
wouldn't like to guarantee that this means that the action is atomic.

Chris

--
Real address: chris at lowth dot sea oh em.
For free GPL e-mail virus blockade ...
  http://protector.sourceforge.net

 
 
 

Is the shell command "mv" atomic

Post by Dragan Cvetkovi » Sat, 05 Apr 2003 00:54:30




> > mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
> > the race condition you describe cannot occur.  Your script is safe.

> No: Not true for all Unixes - some have "rename" as a system, and for others
> "rename" is library call that uses link and unlink to do it's work.

> Under linux (for example) - "rename" is indeed a system call - but I
> wouldn't like to guarantee that this means that the action is atomic.

Well, POSIX requires it. Here is the quote from OpenGroup specification for
rename(2) (in Rationale):

    This rename() function is equivalent for regular files to that defined
    by the ISO C standard. Its inclusion here expands that definition to
    include actions on directories and specifies behavior when the new
    parameter names a file that already exists.  That specification
    requires that the action of the function be atomic.

Note the last sentence there.

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 
 
 

Is the shell command "mv" atomic

Post by Barry Margoli » Sat, 05 Apr 2003 02:32:34





>> mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
>> the race condition you describe cannot occur.  Your script is safe.

>No: Not true for all Unixes - some have "rename" as a system, and for others
>"rename" is library call that uses link and unlink to do it's work.

I don't think any systems that use link/unlink have been produced for many
years.  Can you give an example of a version of Unix less than 10 years old
that works like that?

--

Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

Is the shell command "mv" atomic

Post by Andrew Giert » Sat, 05 Apr 2003 05:45:41


 >> mv(1) uses rename(2) to do its work.  rename(2) is atomic.
 >> Therefore, the race condition you describe cannot occur.  Your
 >> script is safe.

 Chris> No: Not true for all Unixes - some have "rename" as a system,
 Chris> and for others "rename" is library call that uses link and
 Chris> unlink to do it's work.

only really ancient systems (pre-POSIX, so >15 years old) have library
implementations of rename, so you can forget about that.

Standards from POSIX.1-1988 onwards have imposed atomicity
requirements on rename() that effectively require it to be a system
call (such implementation details are of course outside the scope of
the standard, but it is impossible to meet the requirements of POSIX
rename() by using POSIX link() and unlink()).

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>

 
 
 

Is the shell command "mv" atomic

Post by Chris Lowt » Sat, 05 Apr 2003 07:32:01





>> > mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
>> > the race condition you describe cannot occur.  Your script is safe.

>> No: Not true for all Unixes - some have "rename" as a system, and for
>> others "rename" is library call that uses link and unlink to do it's
>> work.

>> Under linux (for example) - "rename" is indeed a system call - but I
>> wouldn't like to guarantee that this means that the action is atomic.

> Well, POSIX requires it. Here is the quote from OpenGroup specification
> for rename(2) (in Rationale):

>     This rename() function is equivalent for regular files to that defined
>     by the ISO C standard. Its inclusion here expands that definition to
>     include actions on directories and specifies behavior when the new
>     parameter names a file that already exists.  That specification
>     requires that the action of the function be atomic.

> Note the last sentence there.

> Bye, Dragan

I stand corrected! Thanks.

Chris
--
My real address is: chris at lowth dot sea oh em
-> OpenSource e-mail virus protection : http://protector.sourceforge.net
-> iptables configuration wizards : http://www.lowth.com/LinWiz

 
 
 

Is the shell command "mv" atomic

Post by Villy Kru » Tue, 06 May 2003 21:33:20


On Thu, 03 Apr 2003 17:32:34 GMT,




>>> mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
>>> the race condition you describe cannot occur.  Your script is safe.

>>No: Not true for all Unixes - some have "rename" as a system, and for others
>>"rename" is library call that uses link and unlink to do it's work.

>I don't think any systems that use link/unlink have been produced for many
>years.  Can you give an example of a version of Unix less than 10 years old
>that works like that?

There is a subtle but important difference when the new name already
exists.  rename(2) will replace the new name if it already exists,
whereas link(2) will fail if you try to create a name which already
exists.  The algorithm for creating lock files usualy uses the link(2)
call to test and creat a file name in an atomic manner in such a way
that an existing file can't be replaced.

Villy

 
 
 

Is the shell command "mv" atomic

Post by Pascal Bourguigno » Thu, 08 May 2003 13:31:33



> On Thu, 03 Apr 2003 17:32:34 GMT,




> >>> mv(1) uses rename(2) to do its work.  rename(2) is atomic.  Therefore,
> >>> the race condition you describe cannot occur.  Your script is safe.

> >>No: Not true for all Unixes - some have "rename" as a system, and for others
> >>"rename" is library call that uses link and unlink to do it's work.

> >I don't think any systems that use link/unlink have been produced for many
> >years.  Can you give an example of a version of Unix less than 10 years old
> >that works like that?

> There is a subtle but important difference when the new name already
> exists.  rename(2) will replace the new name if it already exists,
> whereas link(2) will fail if you try to create a name which already
> exists.  The algorithm for creating lock files usualy uses the link(2)
> call to test and creat a file name in an atomic manner in such a way
> that an existing file can't be replaced.

> Villy

mv is able to do cp/rm when you're moving accross fiel systems.
Otherwise, in the cases where it uses rename, it should be atomic.

--
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

 
 
 

1. Bizzare "cp" and "mv" commands

It looks like some Solaris 2.3 commands have difficulties with proper
diagnosing remote (via NFS)  source files access permissions.

The "/usr/bin/cp" ("/usr/bin/mv")  removes target file
when executed by "root" and source file is not accessible (placed on
the remote machine which doesn't export it with "root" access).

Hope it is a bug and not OS feature. Please correct me if I am wrong.

Solaris 1, and GNU's versions of "cp", "mv"  don't have
this problem.

The "/usr/bin/cat" (SunOS4, SunOs5) command comes with different error
reports in similar circumstances.


 Math. & Computer Sc. Dept.     phone: (+45) 98 15 85 22 ext. 5027
 Aalborg University             direct: (+45) 98 15 42 11 - 5027
 Frederik Bajers Vej 7          fax: (+45) 98 15 81 29
 DK-9220 Aalborg, Denmark  

++++++++++++++++++++++++++++
Examples of destructive "cp" command (removes target even if no access to
source is granted):

      root - dangerous behaviour
# ls -l
total 8
-r--------   1 root     other        486 Mar 24 12:06 shadow
# pwd
/tmp/t
# ls -l
total 8
-r--------   1 root     other        486 Mar 24 12:06 shadow
# cp /net/pico/MASTER/etc/shadow /tmp/t/shadow
cp: /tmp/t/shadow: Permission denied
# ls -l
total 0            # FILE IS GONE
# pwd
/tmp/t
#

     normal user  - OK
total 8
-r--------   1 wap      wap          980 Mar 24 12:08 passwd
cp: cannot open /net/pico/MASTER/etc/shadow: Permission denied
total 8
-r--------   1 wap      wap          980 Mar 24 12:08 passwd
/tmp/t

+++++++++++++++++++++++++++++

Examples of misleading error reports (SunOS4 and SunOS5) from the "cat" command
when file is accessed from the remote host (via NFS). File system
is not exported with "root access".

       root  - wrong error message
# /usr/bin/cat /net/pico/MASTER/etc/shadow
cat: write error: Permission denied
     ^^^^^^^^^^^??????

       normal user - OK
cat: cannot open /net/pico/MASTER/etc/shadow

++++++++++++++++++++++++++++

2. Raw vs. Cooked files: the diff?

3. == lower the priority of commands such as "cp" or "mv" ==

4. Looking for a software pkg...

5. GETSERVBYNAME()????????????????????"""""""""""""

6. Recomandation for a DVD RW

7. Run C shell with "rlogin" and/or "xterm" commands

8. System commander Dual OS install help

9. "write" "to" "flon" commands

10. """"""""My SoundBlast 16 pnp isn't up yet""""""""""""

11. SSA/Veritas: use "vxassist move" or "vxsd mv"

12. "weof" operation in "mt" command gives "permission denied"

13. Problem "mv"ing to DOS partition, "cp" is ok....