Moving files from 400 directories into one directory

Factual Questions
1

The hard drive crashed in my general-purpose home desktop PC the other day. Nothing would restore it to proper readability (I tried quite a few tools), but a utility called Photorec worked on the drive for 27 hours and recovered a great many files (hundreds of thousands of them*) and placed them in a collection of some 500 separate directories on the destination volume.

So now I need to sift through the ashes and see what’s worth keeping, but it’s spread across hundreds of folders (photorec does this so you can start scrutinising the results while the recovery is ongoing, I think)

I’ve deleted a whole load of files I know I’m not interested in, from the Windows command line (by navigating to the folder containing the recovered subfolders and doing Del *.dll /s), but now I want to move all files of a given type into folders of their own, so I can browse all examples of one type of file together.
If I do XCopy with the /s switch, it will find them all, but it will just replicate the subfolder structure at the destination. I want to flatten the structure by one branch.

I tried searching for files of a specified type using the Windows search tool, but the hits were too numerous to be manageable - there are many thousands of files of some types.

So how can I do this? I have Windows XP and Ubuntu Linux 10.10 at my disposal.
*Some of them are icons, sounds, etc that must have been embedded in executables or dlls, etc, but the recovery process has reconstructed them as distinct files.

2

Boy, I just dug something out of the depths of my brain that I thought was gone forever. Behold the “FOR” loop:

for /R c:\dir1 %f in (.) do copy %f c:\dir2

To move files of just a single type, like *.mp3 files:

for /R c:\dir1 %f in (*.mp3) do copy %f c:\myMP3Dir

3

Brilliant - that does exactly what I needed. Thanks!

4

Just so you know, you can also do this with Windows Explorer (the GUI) by doing a search in the parent folder and looking for files of type whatever. The results will be unfolderized and you can just drag the whole list of them into another folder.

5

Yes. To flesh that out a little, view windows explorer in split pane mode with directories on the left and files on the right. In the search box (upper right) put in . and hit enter.

Go make a cup of tea, relax, have a cookie.

When you come back, all the files will be listed together.

sort by name.

select the first file, then press cntl-shft-end and all files will be highlighted.

right click and say cut (or copy).

select the target directory in the left pane, right click and say “paste”. All the files will be in that directory now

Even though you don’t actually move the files (just the reference in the file allocation tables) it will still take a while.

If you do move files between drives, get teracopy (free) - much faster than windows copy - Products - Code Sector

You may also want to get fast duplicate file finder (free), but be warned that searching and matching a few hundred thousand files will take overnight - at least. It goes faster if you break it into sub directories and do the job piecemeal.

6

Be careful here! Make sure you don’t have any duplicate filenames.

7

Good call. Using the GUI can help with this since you can tell it to automatically rename duplicates (once it finds the first one).

8

The GUI ground to a halt when I tried doing it that way (I mentioned this). It wasn’t even happy when I searched for the items I wanted to delete, just because they were so numerous.

9

The main reason that command line stuff hasn’t been completely purged from my brain is that the GUI is just so slow when trying to do this kind of stuff. I still do dir /s to search multiple directories for files because it’s about a gazillion times faster than the GUI-based search.

10

Not if you use an indexed search.

(But it’s stupid that Windows only indexes a few directories by default)

11

I turned off indexing because of the CPU overhead. Granted, it makes this particular task more difficult, but this is a highly exceptional circumstance. I don’t usually need to perform searches at all on my computer, because I know where to find my stuff.

I wonder if indexing really would have helped here though - the recovery process created 500 subfolders filled with assorted files - the first decision I made after it had finished was that I didn’t need to bother keeping .dll files - there were several hundred thousand of them. A non-indexed search found them within an acceptable time, but when I selected them and hit Shift+Delete, the system started to chug and became progressively less responsive (at the same time as not appearing to even start deleting anything). I think it just choked on the sheer magnitude of the task.

12

No, indexing wouldn’t have helped here – in the time it’d take to search and index all the files, you could instead just delete them as you go (as you’ve done).

But for general use, using indexed search vs browsing can be much faster as long as you remember what you call things or how to search for them. (For example, typing part of a song name instead of browsing to music then artist then album then song)

ETA: Sorry, I realize what you’re saying now. I misread Athena’s comment and didn’t realize it applied specifically to this case. Oops :smack:

13

Then you have to put up with slow & buggy Windows indexing running all the time. And that’s from a pro-MS person who generally likes Windows. But I’ve never had any luck with their indexing (or anyone else’s, for that matter. Google Desktop really got slow after running it a few months.)

Granted, it seems better in Windows 7 (on a mega machine with tons of memory) but still, the DOS search isn’t un-handy enough that I want to turn on Windows indexing for my entire machine.