0

I wanted to move binary files from folder /myhome/sourcedir to /myhome/targetdir. I used a command find /myhome/sourcedir -type f -cmin +3 -exec mv '{}' /myhome/targetdir ';'

Folder /myhome/sourcedir existed before this command executed, but folder /myhome/targetdir did not exist. I just forgot to create /myhome/targetdir.

Result of this command - new file /myhome/targetdir was created. File is very big and contain lots of strange symbols ))

How to restore all my files?

  • Tip: when you know that something is a directory, type /myhome/targetdir/. The trailing / forces the file to be a directory. Then mv would have complained mv: accessing ‘/myhome/targetdir/’: Not a directory – Gilles 'SO- stop being evil' Apr 25 '15 at 12:51

1 Answers1

6

Assume the find found 3 files: a, b, and c. This resulted in 3 commands:

mv a /myhome/targetdir
mv b /myhome/targetdir
mv c /myhome/targetdir

so, a was renamed to /myhome/targetdir, then b was renamed to /myhome/targetdir (destroying what used to be a), and then c was renamed to /myhome/targetdir, destroying what used to be b. file c is fine (it has just been renamed). The other files are in trouble. Have a look at Can overwritten files be recovered?. You might be able to recover something.

In the future, using:

mv -t /myhome/targetdir '{}' 

Would be safer.

  • This is one of my pet peeves against Unix: that cp and mv with two arguments do conceptually quite different things depending on whether the second argument is an existing directory or not. – Bjorn Munch Apr 24 '15 at 19:08
  • @Bjorn, it can lead to some disastrous results, but it does seem like a pretty natural syntax to me. What would the alternative be? Seperate mv and rename commands? – James Scriven Apr 24 '15 at 19:24
  • My pet peeve is that there is probably tons of free space on the hard drive; it should be trivial to recover any file until the space needs to be reclaimed (unless I shred it). – James Scriven Apr 24 '15 at 19:24