I have looked everywhere for a tool or script or anything to do this. The few I found or wrote all failed. Yet I can copy each name from the list, paste it into the everything search bar and get an immediate find for each one if it is anywhere in that folder. The thing is, there are over 2000 names. The folder contains at least 40,000 files. In a directory list they would be as in c:\levela\levelb\levelc\"name.pdf". This is a SHORT example as some may be 5 levels deep. But Everything has never failed to find them if they are there. The list of filenames is spelled "exact;ly" as the file would be all the way down to the spaces and commas.
but these pdf's could be in anywhere in that pile of 40,000 others.
Once Everything finds the file, I just copy and paste in into another folder that will eventually contain all the files on my list.
It is the eventually part i would like to shorten if there is some way to get the list to be fed into everything as a "find all these files" at one time or find them one at a time, make a copy of what is found, then go the the next name.
It is very likely that some names will also Not be found at all. I have tried at least 20 programs to accomplish this and not one can handle the List of names as an input parameter.
I LOVE Everything as a search tool and recommend it to everyone i meet, I sure hope there is a way to do what i need with it.
use everything to find all files in a list
Re: use everything to find all files in a list
Not quite understanding what you're trying to do?
If you have:
Why not just create a batch file to copy or move your wanted files into your new directory?
If a particular file, say file2, does not exist, so what.
It has found file1 & copied that & you want that.
It has found file3 & copied that & you want that.
(Use XCOPY or some other copy for additional options.)
In Everything you could search for .pdf, sort by Path, & assuming your directory structures are conducive, then highlight a section of wanted files & drag (or shift+drag or copy...) into your new directory.
(Sometimes operations like that have a tendency to cause Everything to crash, but just fire it up again & continue.)
If you have:
Code: Select all
c:/levela/levelb/levelc/file1
c:/levela/levelb/levelc/file2
c:/levela/levelb/levelc/file3
Code: Select all
COPY c:/levela/levelb/levelc/file1 x:/newdir/
COPY c:/levela/levelb/levelc/file2 x:/newdir/
COPY c:/levela/levelb/levelc/file3 x:/newdir/
It has found file1 & copied that & you want that.
It has found file3 & copied that & you want that.
(Use XCOPY or some other copy for additional options.)
In Everything you could search for .pdf, sort by Path, & assuming your directory structures are conducive, then highlight a section of wanted files & drag (or shift+drag or copy...) into your new directory.
(Sometimes operations like that have a tendency to cause Everything to crash, but just fire it up again & continue.)
-
questorfla
- Posts: 6
- Joined: Sat Feb 28, 2015 5:11 am
Re: use everything to find all files in a list
The problem is that you are assuming I want to copy one "tree" to another "tree" in that exact manner.
I have a Text list of around 2000 filenames.
The list.txt is like this:
Smith, John west Bentley branch-east.pdf
Carol, Jane north Bentley branch-east.pdf
Jim, Mason Carrolton main branch.pdf
and so on for a total of over 2000 filenames.
There is no specific path it is just a text list of filenames.
I have managed to extract all the files now so they are all in a single folder but looking through 70,000 pdf files to find the 2000 or so that match the list is extremely tedious:
hey have to match exactly by name I just need to copy them to the flash-drive and do not care about the path. I need the file.
I can use everything on a right-click search the folder, paste in ONE name and it finds it, then I copy if to the flash-drive.
This list of filenames is a filter of sorts that I have to filter out ONLY the filenames on the list to be copied The path to the file is irrelevant other that as needed to locate it and once located I need to copy it to a flash drive to be taken to another system.
Every name I copy and pated into Everything was located instantly and I was able to make a copy of that file onto a flash drive.
But there are still over 2000 left. I can only copy past so many time before having to take a break.
I was hoping to be able to use everything "programmatically" to automate this tedious chore.
The "pile of files" I have to search through at last check was closer to 70,000 files and finding the 2000 ones I need is not as simple as you may thing. The name examples above are far from the most complex many of them look like close matches but are not exact.
I hope this makes the problem clearer I do not know a better way to state this. Looking for all files in a folder that match a text list of filenames and copying the matching files to a flash drive.
I have had several people offer of simple scripts to do this but they all fail, perhaps due to the spaces in the name or maybe due to the comma or some other character but Everything has never failed to find the match. So I am using it as it is the only thing that works.
I have a Text list of around 2000 filenames.
The list.txt is like this:
Smith, John west Bentley branch-east.pdf
Carol, Jane north Bentley branch-east.pdf
Jim, Mason Carrolton main branch.pdf
and so on for a total of over 2000 filenames.
There is no specific path it is just a text list of filenames.
I have managed to extract all the files now so they are all in a single folder but looking through 70,000 pdf files to find the 2000 or so that match the list is extremely tedious:
hey have to match exactly by name I just need to copy them to the flash-drive and do not care about the path. I need the file.
I can use everything on a right-click search the folder, paste in ONE name and it finds it, then I copy if to the flash-drive.
This list of filenames is a filter of sorts that I have to filter out ONLY the filenames on the list to be copied The path to the file is irrelevant other that as needed to locate it and once located I need to copy it to a flash drive to be taken to another system.
Every name I copy and pated into Everything was located instantly and I was able to make a copy of that file onto a flash drive.
But there are still over 2000 left. I can only copy past so many time before having to take a break.
I was hoping to be able to use everything "programmatically" to automate this tedious chore.
The "pile of files" I have to search through at last check was closer to 70,000 files and finding the 2000 ones I need is not as simple as you may thing. The name examples above are far from the most complex many of them look like close matches but are not exact.
I hope this makes the problem clearer I do not know a better way to state this. Looking for all files in a folder that match a text list of filenames and copying the matching files to a flash drive.
I have had several people offer of simple scripts to do this but they all fail, perhaps due to the spaces in the name or maybe due to the comma or some other character but Everything has never failed to find the match. So I am using it as it is the only thing that works.
Re: use everything to find all files in a list
Everything Command-line Interface
my_pdf_list.TXT:
Then use Everything (ES command line), something like this:
That finds your wanted filenames & dumps the full file name+path into a file.
Then with that:
This then takes that set of file pathnames, sticks a COPY command before the name, then appends "F:" (your Flashdrive drive letter) as the copy to location & writes that for each file into a batch file that you then run to do the actual copy.
copymypdf.bat:
Now you might need to fart around with quotes in case they're needed or what not, so maybe "%%i". ES has options, type ES -h to see them. Start small. Use PAUSE in your batch files & ECHO to see how your variables are expanding... Explore FOR, FOR /? & COPY /?... Maybe XCOPY will work better...
my_pdf_list.TXT:
Code: Select all
Smith, John west Bentley branch-east.pdf
Carol, Jane north Bentley branch-east.pdf
Jim, Mason Carrolton main branch.pdf
Code: Select all
for %%i in (my_pdf_list.TXT) do es %%i >> found_file_pathnames.TXT
Then with that:
Code: Select all
for %%i in (found_file_pathnames.TXT) do echo COPY %%i F: >> C:\TMP\copymypdf.bat
copymypdf.bat:
Code: Select all
COPY Smith, John west Bentley branch-east.pdf F:
COPY Carol, Jane north Bentley branch-east.pdf F:
COPY Jim, Mason Carrolton main branch.pdf F:
Re: use everything to find all files in a list
The above is in pseudo-code, BTW.
The initial 'for' should be more like:
The initial 'for' should be more like:
Code: Select all
for /F "tokens=*" %%i in (king.TXT) do es c: -w %%i >> found_file_pathnames.TXT
Re: use everything to find all files in a list
So I plugged an old Flash drive in that I was looking to reformat.
And thought to myself, wonder if I have all the files on the drive on my HDD?
DIR /B /S /AA > king.txt
(It's a kingston drive)
/B = bare, /S = subdirectoires, /AA = files with the archive attribute set (I did not want to pick up directory names)
But that gives you a full pathname to each file
(Like: D:\BIN\777.exe)
So in Vim, %s/^.*\\// while leaves only the file name itself
Now throw that file, king.txt to the above 'for', gives me a list of found files on my C: drive
And that again has the full pathname, so Vim to fix that up
After that I compare king.txt with found_file_pathnames.TXT & files found only in found_file_pathnames.TXT I know are not on my C: drive
Now in this case, I know my results are not going to be exact, but they are close enough for my purposes
Depending on list size, this is relatively inefficient.
A few hundred items is bearable. A few thousand really points out the inefficiency (at least in how I've gone about it).
[Eh, 4300 items, just too inefficient. Note that restricting es.exe to a single drive, C: in my case, appears to make the search slower?]
Alternatively, suppose I could have used a Duplicate File Finder, had it search my C: & compare against D: (my Flash drive in this case)... [pending]
Duplicate Cleaner (Pro, aka paid version) has an option to "not scan against self", IOW I can compare C: to D: without comparing C:/x/* to C:/y/*, only something like C:/x/* to D:/z/*, & for something like this, it makes if far more efficient. Search for same Name & Size. I know that size will cause me to come up with less then what I would have otherwise, be it will be a more exact search. (Exact enough, for my purposes.) Anyhow, it took 5:30 to scan both drives & perform the comparison. (By far the majority of the time was in the actual scanning of the drives, enumerating the file names [something Everything excels at
] & sizes.)
Once done, a simply matter of selecting all "duplicate" files from D: drive & deleting them (with very little fear of deleting something "important").
Subsequent scan, only by file names [even though more error prone] completed in 4:min. KInd of expected it to be faster, but guess there was too much data involved for what maybe have been cached to be too effective. A lot more data involved, but filtering with Duplicate Cleaner made it less of a choir. Even so, less then optimal way to go about it.
For instance I could have limited the directory trees scanned on C:. I know there were worthless trees on D: that I could have pruned from the onset. And even at that a lot of the comparisons would have been better done directly from my File Manger & its File Comparator feature.
And thought to myself, wonder if I have all the files on the drive on my HDD?
DIR /B /S /AA > king.txt
(It's a kingston drive)
/B = bare, /S = subdirectoires, /AA = files with the archive attribute set (I did not want to pick up directory names)
But that gives you a full pathname to each file
(Like: D:\BIN\777.exe)
So in Vim, %s/^.*\\// while leaves only the file name itself
Now throw that file, king.txt to the above 'for', gives me a list of found files on my C: drive
And that again has the full pathname, so Vim to fix that up
After that I compare king.txt with found_file_pathnames.TXT & files found only in found_file_pathnames.TXT I know are not on my C: drive
Now in this case, I know my results are not going to be exact, but they are close enough for my purposes
Depending on list size, this is relatively inefficient.
A few hundred items is bearable. A few thousand really points out the inefficiency (at least in how I've gone about it).
[Eh, 4300 items, just too inefficient. Note that restricting es.exe to a single drive, C: in my case, appears to make the search slower?]
Alternatively, suppose I could have used a Duplicate File Finder, had it search my C: & compare against D: (my Flash drive in this case)... [pending]
Duplicate Cleaner (Pro, aka paid version) has an option to "not scan against self", IOW I can compare C: to D: without comparing C:/x/* to C:/y/*, only something like C:/x/* to D:/z/*, & for something like this, it makes if far more efficient. Search for same Name & Size. I know that size will cause me to come up with less then what I would have otherwise, be it will be a more exact search. (Exact enough, for my purposes.) Anyhow, it took 5:30 to scan both drives & perform the comparison. (By far the majority of the time was in the actual scanning of the drives, enumerating the file names [something Everything excels at
] & sizes.)Once done, a simply matter of selecting all "duplicate" files from D: drive & deleting them (with very little fear of deleting something "important").
Subsequent scan, only by file names [even though more error prone] completed in 4:min. KInd of expected it to be faster, but guess there was too much data involved for what maybe have been cached to be too effective. A lot more data involved, but filtering with Duplicate Cleaner made it less of a choir. Even so, less then optimal way to go about it.
For instance I could have limited the directory trees scanned on C:. I know there were worthless trees on D: that I could have pruned from the onset. And even at that a lot of the comparisons would have been better done directly from my File Manger & its File Comparator feature.