I drag and drop a folder into another by mistake in FileZilla.


The folder got moved is a very huge one. It includes hundreds of thousands of files (node_modules, small image files, a lot of folders)

What is so weird is that after I release my mouse, the moving is done. The folder "big_folder" is moved into "some_other_folder".


(there is no big_folder in the ~/ after moving)

Then I realize the mistake and try move back but it fails both on FileZilla and terminal.

Then I have to cp -r to copy files back because there are server-side codes accessing those files in ~/big_folder

And it takes like forever to wait ...

What should I do?

BTW, here are the output from FileZilla (it's the failure of the moving back):

Status:       Renaming '/root/big_folder' to '/root/some_other_folder/big_folder'
Status:       /root/big_folder -> /root/some_other_folder/big_folder

Status:       Renaming '/root/some_other_folder/big_folder' to '/root/big_folder'
Command:  mv "big_folder" "/root/big_folder"
Error:          mv /root/some_other_folder/big_folder /root/big_folder: received failure with description 'Failure'
  • 40
    Ah, the most useful of error messages, received failure with description 'Failure'. Jul 9, 2018 at 16:09
  • 3
    Go to a terminal, and type in the command mv /root/some_other_folder/big_folder /root/big_folder. What error message do you get? Jul 9, 2018 at 16:15
  • I would probably go with cp -al
    – Nemo
    Jul 9, 2018 at 16:28
  • 1
    OP's mv vs cp question is addressed, but I would love to hear why he was able to move the folder in one direction instantly but not the other. Jul 9, 2018 at 17:46
  • 4
    For essentially the same reason that it's much faster to move a book from one room to another than to create a copy of the book. Jul 10, 2018 at 17:50

2 Answers 2


If a directory is moved within the same filesystem (the same partition), then all that is needed is to rename the file path of the directory. No data apart from the directory entry for the directory itself has to be altered.

When copying directories, the data for each and every file needs to be duplicated. This involves reading all the source data and writing it at the destination.

Moving a directory between filesystems would involve copying the data to the destination and removing it from the source. This would take about as long time as copying (duplicating) the data within a single filesystem.

If FileZilla successfully renamed the directory from ~/big_folder to ~/some_other_folder/big_folder, then I would revert that using

mv ~/some_other_folder/big_folder ~/big_folder

... after first making sure that there were no directory called ~/big_folder (if there was, the move would put big_folder from some_other_folder into the ~/big_folder directory as a subfolder).

  • 9
    Oh ... is that why I see the word "renaming" rather than "moving" in the output? Jul 9, 2018 at 15:08
  • 3
    @AGamePlayer Yes, correct.
    – Kusalananda
    Jul 9, 2018 at 15:10
  • 4
    @AGamePlayer "Failure" is unfortunately not a good error description. I would have used mv ~/some_other_folder/big_folder ~/ after making sure there is no other big_folder in the home directory. I have never used FileZilla.
    – Kusalananda
    Jul 9, 2018 at 15:13
  • 11
    Another reason not to depend on Windows GUI tools to do some file maintenance on Unix. Jul 9, 2018 at 15:45
  • 4
    @MarkStewart why “on Unix” at the end of your comment?; Is there a time when it is a good idea? Jul 9, 2018 at 16:13

The existing answer is great, but I'd like to expand on it a bit by showing exactly what is happening when you move versus when you copy a file. When you look at the syscalls during a copy, you see:

open("hello1.txt", O_RDONLY)               = 3
open("hello2.txt", O_WRONLY|O_CREAT, 0644) = 4
read(3, "Hello, world!\n", 4096)           = 14
write(4, "Hello, world!\n", 14)            = 14
close(3)                                   = 0
close(4)                                   = 0

This opens the source file, then creates a second file. It then reads the contents of the source file to memory and writes that memory to the destination file. This requires several context switches and some disk I/O which can be quite high for large files. If you move a file however, you see:

rename("hello1.txt", "hello2.txt")         = 0

It's important to remember that you will only see the file be renamed if it is on the same filesystem on the same physical disk. If you create a huge, multi-gigabyte file and then move it between two locations in your home, you will notice the action completes instantly. If, on the other hand, you move it to an external device, it will take as long to move as if you used cp instead. The syscall trace would be identical to the first one, but with unlink("hello1.txt") at the very end. This is because renaming can only be used to move a file if the source and destination are on the same filesystem.

  • The OP moved a directory, not a file.
    – A.L
    Jul 10, 2018 at 7:21
  • 1
    It does still apply tho, unless OP is moving empty folders, which would be the only case where no files are involved
    – glace
    Jul 10, 2018 at 10:13
  • 2
    @A.L In Unix-like systems everything is a file.
    – Thegs
    Jul 10, 2018 at 17:50
  • 1
    @A.L A text file was just an example. For a directory, the only difference is that you would have some getdents() and mkdir() calls sprinkled around.
    – forest
    Jul 10, 2018 at 21:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .