8

Is moving a file via the mv command between two filesystems an atomic operation?

dr_
  • 29,602
XgigPro
  • 103
  • My impression or is it the 2nd time you are asking this here in the last few days? – Rui F Ribeiro Jun 29 '18 at 12:21
  • 1
    This is my first question here. – XgigPro Jun 29 '18 at 12:29
  • 3
    Can someone tell me why the question is getting down votes? I feel the question is simple ,yet meaningful and complete. – XgigPro Jun 29 '18 at 12:33
  • FWIW, there was another take on this subject just a few days prior to this: https://unix.stackexchange.com/q/452084/170373 . Might explain some of the downvotes, then again, it might just be that the downvoters take this as "plain obvious". Hard to say. – ilkkachu Jul 03 '18 at 21:07

2 Answers2

12

See the EXDEV error (in man 2 rename):

   EXDEV  oldpath and newpath are not  on  the  same  mounted  filesystem.
          (Linux  permits  a  filesystem to be mounted at multiple points,
          but rename() does not work across different mount  points,  even
          if the same filesystem is mounted on both.)

You can't move between file-systems with a system call, so what mv does is a user-space copy and delete, which is never atomic.

ctrl-d
  • 952
  • Note that that documentation is Linux-specific; POSIX allows this error but implementations are allowed to diverge. – Stephen Kitt Jun 29 '18 at 12:03
  • You are not correct, it could be implemented in a way that would make it behave as if it was atomically. It just isn't since the mv(1) program does not implement it's copy routine the right way. – schily Jun 29 '18 at 12:06
  • @Stephen Kitt: Correct, ZFS permits a rename(2) between different filesystems in case they are on the same ZPOOL. – schily Jun 29 '18 at 12:07
  • 2
    @ schily You can always interrupt the process between the system calls. How would your method do the atomic move? – ctrl-d Jun 29 '18 at 12:38
  • @ctrl-d: a sycall may be interrupted by a power outage. So you always need just a method that is transaction based and allows a rollback. – schily Jun 29 '18 at 13:26
  • You can never have a file disappear in one place and appear in another place without there being time in-between which can be intruded by other processes. Only the kernel can keep other processes out of that time period. So only system calls can do such a thing. – ctrl-d Jun 29 '18 at 13:37
  • You are wrong again even though you have been given an explanation that there is no difference between kernel and userland. – schily Jun 29 '18 at 13:48
  • 1
    Please provide an atomic move function in C then – ctrl-d Jun 29 '18 at 14:50
-2

This depends on what you understand by "atomically".

Unlike the rename() syscall, copying files bewteen two filesystems is usually not atomically. Since the copy routine in mv does not call fsync(2), there may be late filesystem errors that are not detected.

schily
  • 19,173
  • 5
    It's never atomic across filesystems. – Chris Davies Jun 29 '18 at 12:19
  • As mentioned, you are mistaken since it is possible to implement things in a way that makes it look like it was atomic and behave as if it was atomic. – schily Jun 29 '18 at 12:22
  • 2
    I would consider the term "atomically" that there's no in-between state possible in the process of moving. – ctrl-d Jun 29 '18 at 12:50
  • 1
    Can you find me a reference for the ZFS rename(2) implementation please? I've looked but can only find it recorded as a wish-list item against the filesystem. (Maybe I'm looking in the wrong places...) – Chris Davies Jun 29 '18 at 13:20
  • It was mentioned either in mails on the OpenSolaris mailing lists or has been part of a talk on a Opensolaris core developers meeting in Sante Cruz. – schily Jun 29 '18 at 13:24
  • 1
    atomic rename has nothing to do with durability (fsync) – Navin Mar 10 '22 at 16:13