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. Commented Mar 24, 2021 at 18:44

1 Answer 1

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
    Commented Mar 24, 2021 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
    Commented Mar 24, 2021 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
    Commented Mar 24, 2021 at 22:43
  • Glad I could help :)
    – xhienne
    Commented Mar 24, 2021 at 22:59

You must log in to answer this question.

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