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'
  • 37
    Ah, the most useful of error messages, received failure with description 'Failure'. – Captain Man Jul 9 '18 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? – ctrl-alt-delor Jul 9 '18 at 16:15
  • I would probably go with cp -al – Nemo Jul 9 '18 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. – user1717828 Jul 9 '18 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. – David Richerby Jul 10 '18 at 17:50

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).

  • 6
    Oh ... is that why I see the word "renaming" rather than "moving" in the output? – AGamePlayer Jul 9 '18 at 15:08
  • 2
    @AGamePlayer Yes, correct. – Kusalananda Jul 9 '18 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 '18 at 15:13
  • 10
    Another reason not to depend on Windows GUI tools to do some file maintenance on Unix. – Mark Stewart Jul 9 '18 at 15:45
  • 4
    @MarkStewart why “on Unix” at the end of your comment?; Is there a time when it is a good idea? – ctrl-alt-delor Jul 9 '18 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 partition 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. This is because moving a file can only be done by renaming it if it is on the same partition.

  • The OP moved a directory, not a file. – A.L Jul 10 '18 at 7:21
  • 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 '18 at 10:13
  • @A.L In Unix-like systems everything is a file. – Thegs Jul 10 '18 at 17:50
  • @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 '18 at 21:53

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.