1

When moving a directory to another drive, if there are errors in the process, nothing will be deleted. I am getting this kind of errors:

mv: cannot stat ‘originaldirectory/longpath/irrelevantfile’: Input/output error

I would like mv to:

  • retry a couple of times (it may be that easy, probably that will solve nothing)
  • delete the files that were moved successfully

So that only the problematic files remain in the original folder.

Trylks
  • 383
  • 1
  • 2
  • 9
  • 3
    Hopefully you're aware that an I/O error is something you **should** address ASAP. Running a `fsck -fc /dev/AffectedDevice` while unmounted is most important. – Julie Pelletier Jan 07 '17 at 21:51
  • @JuliePelletier thank you, I still have a lot of things to learn about a lot of things. About `fsck`, `man` tells me that these are the options: `fsck [-lrsAVRTMNP] [-C [fd]] [-t fstype] [filesystem...] [--] [fs-specific-options]`. So I still do not know what that does, but I will do it ASAP. Thank you. – Trylks Jan 07 '17 at 21:56
  • 1
    `fsck` is usually a wrapper that will execute the proper tool after it identifies the filesystem. On mine it does an `e2fsck` which has the `-c` option in its manual. `-f` is to force it even if it doesn't think it needs to be checked. Only do it with the partition unmounted. – Julie Pelletier Jan 07 '17 at 22:12

2 Answers2

4

There are better tools for this than mv. One of my preferred ones is rsync.

rsync --remove-source-files -avHP /path/to/source/ /path/to/destination/

Try it with the --dry-run flag before you use it for real, to see what it would do if it were allowed to do so. Or omit the --remove-source-files flag for it to work more like cp that mv.

The advantage here of rsync over mv is that it's interruptible and repeatable. So when it crashes out because of an error you can just restart it. Or let it run in a loop for a bit:

for try in 1 2 3
do
    rsync --remove-source-files -avHP /path/to/source/ /path/to/destination/ && break

    echo -n 'Pausing...'
    sleep 10 || break
    echo
done
roaima
  • 107,089
  • 14
  • 139
  • 261
2

First, reconstruct the directory tree of the source in the destination:

cd source
find -type d -exec mkdir -p destination/{} \;

The {} in the find should contain the relative path of each directory.

Then, check if the directory tree you created in the destination looks good. And try to move each file individually:

cd source
find -type f -exec mv {} destination/{} \;

I can't tell you enough how potentially dangerous this is. You could lose data! I am not sure what find is going to do if it can't stat a file. My hope is that it will just emit a message error and move on. But since you are apparently trying to recover data from a damage medium, you're probably aware of any risks.

If this works as intended, all that will be left in the source are the directories and the files that couldn't be moved. If you want, you can search on SO how to remove the empty directories recursively (I'm 100% sure this has been asked before) to make your analysis easier.

I suggest you make a small test case in the damaged medium. mkdir a few directories, touch some random files and try these steps to see what happens. Also probably a good idea if you do this in one directory a time instead of doing it in the root.

What I mean is, if your strucutre is, for example:

.
├── dir1
│   ├── fileA
│   └── subdir1
│       └── fileB
├── dir2
│   └── fileC
└── dir3
    ├── subdir1
    │   └── fileD
    └── subdir2
        └── fileE

Then run it 3 times; once in dir1, then if everything runs smooth, move to dir2, and dir3, instead of doing everything at once at ..

giusti
  • 1,797
  • 2
  • 15
  • 30