What happens if mv is interrupted?

Question

What happens if the Linux mv command is interrupted? Say, I'm moving a whole directory to some other place and interrupt it while it's moving. Will the source directory still be untouched?

score 77 · Accepted Answer · edited Aug 27 '19 at 20:32

77

If you move a directory on the same file system, you only move the directory entry from one location in the file system to another one. E.g., mv /source/dir /target/dir will delete the directory entry of dir from /source and create a new one in /target. That's done by one atomic system call (i.e., uninterruptable). The inode containing the directory entries of dir as well as the actual content of the directory itself is not affected.

If you move the directory from one file system to another, all of the files are first copied to the new file system and then unlinked from the original one. So if you interrupt mv while it’s copying, you may end up with two copies of some of the files – at the old location and at the new one.

edited Aug 27 '19 at 20:32

G-Man Says 'Reinstate Monica'

7,678
22
41
87

answered Mar 18 '11 at 09:54

bmk

2,145
14
12

1

This assumes that the source and destination are on the same volume. – Ignacio Vazquez-Abrams Mar 18 '11 at 10:00
Interesting! Also, if interrupted midway a file move, the source file will remain as you said, but the destination will be a partial file? – invert Mar 18 '11 at 12:20
7

@Wesley: No, there will be no partial file. If the system stays up (e.g., you hit ctrl-C), it will be removed automatically. If not (e.g., power loss), the partial file may be left somewhere inaccessible on the destination disk, but should be cleaned up by the next `fsck` (which will most likely run automatically on reboot, since the disk wasn't unmounted cleanly). – Dave Sherohman Mar 18 '11 at 12:42
70

Wrong. If you move dir from one fs to another mv /fs1/dir /fs2/ and you interrupt, /fs1/dir/ will stay here completely. /fs1/dir is removed only when the move is complete. – Oct 13 '13 at 09:30
14

user263131 is right. Run `strace mv /fs1/dir /fs2/` - the **very last thing** mv does is calling `unlinkat` on all source files at once (not one by one as they are copied). – Jakob Jul 05 '14 at 09:58
4

I came here after interrupting a "mv /fs1/*.data /fs2". The data files in fs1 that were copied completely to fs2 are deleted, indicating it's done on a per-file basis as bmk mentioned. Perhaps directories is a special-case, since you can't delete them until all the stuff inside them is out. – J.J Feb 23 '16 at 12:03
9

@J.J Looks like that's because you used a bash expansion, in which case mv treats each file in the expansion as a separate source (thus doing them individually). – gkanwar Sep 09 '16 at 17:52
2

gkanwar is correct. When mv is moving a directory it has to handle the file list scanning internally, when it is done via bash expansion it is handled a list and done one by one. – Stu Apr 26 '17 at 00:57
7

So.... @bmk or others, do you want to update this answer to be less... wrong? – Artem Russakovskii Feb 05 '18 at 00:15
2

@ArtemRussakovskii it's not wrong, it's just nuanced. No matter how you do it you should be "safe" though in the sense that you won't lose your source file if you choose to interrupt mv. – Ezekiel Victor May 04 '18 at 01:14
2

It was not nuanced, it clearly stated that if you interrupt `mv` you will not still have the files in the original location, which is wrong. – kirelagin Aug 21 '19 at 07:54
see also https://unix.stackexchange.com/questions/39813/best-way-to-continue-stopped-move-mv-by-merging-directories – Brian Minton Nov 21 '19 at 21:07

Simon Richter · Answer 2 · 2011-03-18T18:07:26.597

39

The GNU implementation iterates over the arguments on the command line, attempts to rename first, and, if that fails, recursively copies and then recursively deletes the source. So

mv a b c/

will delete a before copying b, and will not start deleting anything in a before the destination copy is complete.

Note that this applies to the GNU implementation only.

To clarify: if a is a directory containing d and e, and b is a file, the order will be

create c/a
copy a/d -> c/a/d
copy a/e -> c/a/e
delete a/d
delete a/e
delete a
copy b -> c/b
delete b

edited Mar 18 '11 at 18:07

answered Mar 18 '11 at 13:18

Simon Richter

2,913
1
21
23

1

Can you provide a source for this? Other answerers are saying a source file is deleted immediately after it is copied to a different fs (i.e. not all copied then all deleted). – jamesbtate Mar 18 '11 at 18:02
2

Experience. I've added an example to make it more clear how my answer and the others are consistent. If you only list individual files then indeed each file will be deleted immediately. – Simon Richter Mar 18 '11 at 18:08
1

I observe the behaviour described in this answer on macOS, that is, with a BSD `mv` as well, so it is not GNU-only. – kirelagin Aug 21 '19 at 07:55

user79878 · Answer 3 · 2017-05-14T05:00:26.787

You move one directory, interrupt the move, and the original directory will stay intact:

$ mv a b/

If you move multiple directories, each one will be intact on either the source or destination, depending on when you interrupted:

$ mv a b c/

How I got my answer:

$ mv --version
mv (GNU coreutils) 8.21

$ info mv
... It first uses some of the same code that's used by `cp -a'
to copy the requested directories and files, then (assuming the copy
succeeded) it removes the originals.  If the copy fails, then the part
that was copied to the destination partition is removed.  If you were
to copy three directories from one partition to another and the copy of
the first directory succeeded, but the second didn't, the first would
be left on the destination partition and the second and third would be
left on the original partition.

As a test, I copied a large folder to an NFS directory, interrupted, and the number of files in my source large folder stayed the same, and partial contents were left on the NFS directory. I used "find . -type f | wc -l" to verify.

Looks like Simon's answer is correct.

score 9 · Answer 4 · answered Jun 29 '14 at 13:58

The accepted answer is definitely wrong about moving between file systems - a fact that saved me a lot of trouble a couple of times already. When moving a directory that containes subdirectories, no file in a subdirectory will be deleted before the whole subdirectory has been copied. This is, btw.the actual meaning of "object by object" - a subdirectory IS an object (file) and thus its integrity has to be preserved by a complete copy at the destination before anything can be deleted. So Simon's answer appears to me as the correct one.

score 5 · Answer 5 · answered May 28 '16 at 16:59

5

If you want to interrupt mv because you want to disconnect from the terminal, you can just send it to background:

* press Ctrl+Z

# bg
# disown

answered May 28 '16 at 16:59

Курочка Ряба

69
1
1

1

That is a good point but it doesn`t answer the actual question. – Julie Pelletier May 28 '16 at 18:53
4

@JuliePelletier, but that's what I was searching for so someone may be interested in doing this. – Курочка Ряба Jun 23 '16 at 13:29

score 4 · Answer 6 · answered Mar 18 '11 at 09:34

4

No. mv operates object by object, so objects that have already been processed will be removed from the source.

answered Mar 18 '11 at 09:34

Ignacio Vazquez-Abrams

111,361
10
201
247

score 3 · Answer 7 · answered Mar 18 '11 at 15:25

Definitely no. The move is made object by object. Hence, the object moved to the destination up to the point of interrupt shall not exist in the source any more.

If mv was issued for a large file (between different) and it has been interrupted then the source will be intact. On the target you will see an incomplete file up to the point of interruption.

You can however restore the mv with the same command and the process will continue.

What happens if mv is interrupted?

7 Answers7

Linked