I wanted to move 'file.txt' one folder up, but instead of mv file.txt ../file.txt I entered mv file.txt ../.

Now the file is gone and I didn't get any error message. So it seems the some action was done successfully. But what happened here?

I have backups, so at least that's no problem. But I'd like to understand what I did and if I changed anything or if this file magically disappeared.

  • 1
    Try ls ../file.txt from the same directory. – depquid Apr 2 '13 at 16:54
  • @depquid: Oh, there it is. Why can't I see it with ls in the parent folder?! – unor Apr 2 '13 at 17:06
  • Did you follow a symlink to get to one of the directories? Sometimes goofy/unintuitive things happen when working with symlinked directories. – depquid Apr 2 '13 at 17:09
  • @depquid: Yeah, the directory where the file was originally placed is a symlink in my home directory. – unor Apr 2 '13 at 17:40
  • You're real issue here is the symlinks and how cd and mv behave differently when dealing with them. I've created an answer which addresses that. You should probably also add info to your question to reflect this factor. – depquid Apr 2 '13 at 20:32

The file was moved to the actual parent directory of the one you were in, rather than the parent directory of the symlink you followed to get there. By default cd behaves differently than ls or mv when encountering ... cd just goes up the path, effectively reverse-following symlinks, whereas the others go to the actual parent of the directory they are in, regardless of how you got there.

Imagine a directory tree like this (~ is the home directory and shortcut is a symlink to maindir/subdir):

├── maindir/
│   └── subdir/
│       └── file.txt
└── shortcut -> maindir/subdir/

If you simply cd to ~/shortcut then ls will show file.txt, and pwd will show ~/shortcut. However, while the output of pwd is correct according to the symlink you followed to get there, you are actually ("physically", if you will) in ~/maindir/subdir. ls and mv are aware of this, so mv file.txt .. will move file.txt to the actual parent directory: ~/maindir, rather than ~ as you expected.

You can get cd to behave like the others by using the -P switch. So if you are in the directory you originally ran the mv command from (~/shortcut) and run cd -P .., it will take you to the actual parent directory (e.g. ~/maindir), and you will be able to find file.txt there with a simple ls file.txt. (You can also get to the actual current directory with cd -P ..)


mv file.txt .. and mv file.txt ../file.txt have exactly the same effect. There is a subtle distinction in mv:

  • If the last argument is a directory (here ..), you can enter several sources, and they are moved to the destination with the same name(s)
  • If the last argument is not a directory (is a file or doesn't exist), the single source is moved there.

So, if dir is a directory:

mv file1 file2 file3 dir  # Moves the files there
mv file dir               # Moves one file
mv file dir/newname       # Moves file, new name
mv file newfile           # Just renames
  • 1
    You missed a few spaces for the code block at the end there, but I'm not allowed to make edits less than six characters. – depquid Apr 2 '13 at 16:44

mv file.txt ../ is a completely legitimate command: you told the kernel to move a file's name to the parent directory of the current directory. file.txt should not have disappeared, it should still appear in the parent of whatever directory you issued the command.

It's possible that circumstances will modify what happens. For example if ../file.txt already existed, its contents are now those of ./file.txt, and whatever ../file.txt previously contained got deleted.

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.