3

I was trying to batch move images from a folder to new folders that are named by the image (px) size of the images. I used this command to do that:

awk '{system("mv "$1 " ./"$4)}' sizes.log

The content of sizes.log was many lines in this format:

f122441728.jpg        Exif.Photo.PixelXDimension                   Long        1  4032

I am now painfully aware of the shortcomings of this method. I didn't test my command and moved many files into the file "1" because column $4 is "1" in all lines of sizes.log. I realized something was off and aborted the command, but about 500 pictures were deleted.

I am not sure how mv works but, as far as far as I understand, this happened: In each line the file from column $1 got renamed to "1", but the data blocks of the image file remained on the disk.

Is that assumption correct? Do I have a chance of a recovery with photorec for example?

I would have to reassemble a RAID in another machine, but that is something I have had luck with before. I was sorting a run of photorec from another mistake..

edit: After I found a backup of my files (yay!) I have revisited the procedure that led me to my mistake and have used these commands to sort my files into folders that are named by the image size of the pictures.

identify -format "%f %w\n" *.jpg >> siz.log

awk '{system("mkdir ./"$2"/")}' siz.log

awk '{system("mv "$1 " ./"$2"/")}' siz.log

note the trailing slash, that is what got me into trouble before. I missed it and got no error messages from mv.

Farid Stein
  • 31
  • 2
  • 1
    If these files are really important, **power down the system right now** and do not boot it until you've had a chance to **talk to a data recovery specialist**. – tadman Apr 09 '19 at 21:56
  • 1
    @tadman I did that already. Thanks for your reminder! – Farid Stein Apr 09 '19 at 22:02
  • 1
    FYI, I see the argument for the existing close vote due to it not being a programming problem. However, IMO, there is merit to the counter-argument that this is, in fact, a programming problem because the author is trying to fix the consequence of a bug in their shell script. – entpnerd Apr 09 '19 at 22:06
  • Yes, if this is a HDD then there's a fair chance that photorec will be able to recover many of them. When operating within a filesystem, `mv` doesn't actually move or write any data so the backing storage of each image wouldn't have been changed. – that other guy Apr 09 '19 at 22:07
  • I think you've solved your problem, and I don't know the answer to your question anyway. When I do such things, I use awk to print the commands first. Then, once I'm satisfied that they're right, I pipe the awk output to /bin/sh. It's about as efficient, and much faster, once you take into account the MTTR if you make a mistake! – James K. Lowden May 07 '21 at 20:28

1 Answers1

0

If the files still exist and haven't been inadvertently deleted, try using the find command to recursively search for the root directory. This assumes that you have the name of some of the missing files. For example, if you know that one of the files was named abc.jpg, you could search as follows:

find / -name "abc.jpg"

For details, see this canonical answer on the find command.

entpnerd
  • 9,041
  • 5
  • 41
  • 66
  • Will find be able to find files that are not listed by ls anymore? I do have all file names, but I fear you suspect I have moved the files to an unknown location. I did not, unfortunately – Farid Stein Apr 09 '19 at 22:17
  • What do you mean by "not listed by `ls` anymore"? – entpnerd Apr 09 '19 at 22:40
  • But, yes, I did interpret your question as having moved the files to some arbitrary location. – entpnerd Apr 09 '19 at 22:41