1

Through shell shortcuts I accidentally moved a dir into itself and now it seems to have disappeared. Here is the sequence cut-n-pasted directly from the terminal:

$ chmod a+x  load_test_set.sh ~/bin
$ mv !$ ~/bin
mv ~/bin ~/bin
$ ls ~/bin
ls: cannot access /home/jimk/bin: No such file or directory

(the trailing "~/bin" on the chmod was inadvertant and unnoticed until I had screwed things up). I did this in tcsh on CentOS Linux release 7.8.2003.

Is this dir lost forever? Is the space lost to the file system? Can I recover the dir and/or the filesystem space?

Responding to some comments:

I ran "sudo find / -type l -name bin | less", and got:

/var/lib/docker/overlay2/882ace003168e1efea1a6f4c6575e101b625af233a25e9b9fb4cec724bb82ce9/diff/bin /var/lib/docker/overlay2/882ace003168e1efea1a6f4c6575e101b625af233a25e9b9fb4cec724bb82ce9/diff/usr/lib/debug/bin /usr/lib/debug/bin /usr/share/gdb/auto-load/bin /bin

and none of those have a "bin" subdir.

And, yes, I would have expected an error trying to mv a dir into itself... but that cut-n-paste was from the actual sequence when it happened. So it did happen and did not generate an error. (mention of VMWare removed as it was added in error)

1
  • 2
    Are you sure you did this? When I execute exactly these commands, mv fails with mv: cannot move 'sub' to a subdirectory of itself, where sub is the name of my test directory. – rexkogitans Mar 24 at 18:44
4

If ~/bin was a directory, you should have had an error, something like:

mv: cannot move '/home/jimk/bin' to a subdirectory of itself, '/home/jimk/bin/bin'

Since ~/bin has disappeared, I suspect it was a symbolic link rather than a directory. Thus, you ended up moving the symbolic link ~/bin to the directory it was pointing to.

If I'm right, you just have to figure out where that directory is. Use this command for example:

find ~ -type l -name bin

(change find ~ to find / if you don't find it inside your own directory)

On the other hand, if you are 100% sure ~/bin was a directory and it has suddenly disappeared, then this is not normal and I suggest that you fsck your home filesystem.

4
  • I ran "", and got: /var/lib/docker/overlay2/882ace003168e1efea1a6f4c6575e101b625af233a25e9b9fb4cec724bb82ce9/diff/bin /var/lib/docker/overlay2/882ace003168e1efea1a6f4c6575e101b625af233a25e9b9fb4cec724bb82ce9/diff/usr/lib/debug/bin /usr/lib/debug/bin /usr/share/gdb/auto-load/bin /bin and none of those have a "bin" subdir. And, yes, I would have expected an error trying to mv a dir into itself... but that cut-n-paste was from the actual sequence when it happened. – JimK Mar 24 at 20:44
  • At first sight, they all look legit. Assuling this is the result of find -type l, none have a bin subdir because they are symbolic links. One of them might be the one you moved. Look at their ctime (ls -lc): the one that you moved has its ctime set to the time of the move. Also, look at the directory they point to: the one that points to the directory it is currently in is the one you moved. – xhienne Mar 24 at 21:58
  • found it! I had so many windows open I did the "find" on the wrong box :-( It shows up when run in the correct terminal window.... and now I remember why I had a soft link for my bin dir: my home dir is on a volume that is not executable. Thank you xhienne. – JimK Mar 24 at 22:43
  • Glad I could help :) – xhienne Mar 24 at 22:59

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.