GetFiles test

[zedd151]

There are also many \.\.\.\. sequences in your screenshot, which don't make much sense.

I had tons of those in a previous Windows 7 installation, apparently some kind of link or virtual folder; gives you "access denied" if you try to click on the path in Explorer. Also very difficult to get rid of! (My current Windows 7 has none of these.)

Just so you know NoCforMe, none of those show up using 'dir', or my own 'file lister program' (linked above in #12) to get the file listings. Some other oddity happening here. And all files listed by those two methods are accessible.

But just for kicks, I will reinstall Windows 7 later tonight. jj, don't take down the attachments. I wil be testing those with a clean install later tonight. (It's 5:ish PM here right now)

[jj2007]

When you run it with this path, what happens? Can you post the NewF.txt please?

#512,  0 MB  E:\archive\desktops\2023.. 2024\.\.\.\SFSudoku.asm                   
#768,  0 MB  E:\archive\desktops\2023..\solver\.\.\.\solver.asm                   

[zedd151]

When you run it with this path, what happens? Can you post the NewF.txt please?

#512,  0 MB  E:\archive\desktops\2023.. 2024\.\.\.\SFSudoku.asm                   
#768,  0 MB  E:\archive\desktops\2023..\solver\.\.\.\solver.asm                   

The debug version or the original version?

From the debug version:

Code Select Expand

C:\Users\Administrator\Downloads\GetFilesNewDebug>GetFilesNewDebug.exe E:\archiv
e\desktops\2023.. 2024\.\.\.\SFSudoku.asm

Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Scanning E:\archive\desktops\2023.. 2024\.\.\.\SFSudoku.asm

0 ms    for new algo, 1 files, bufsize 4096
0 ms    for old algo, 0 files, ratio   3.104

hit any key

Code Select Expand

C:\Users\Administrator\Downloads\GetFilesNewDebug>GetFilesNewDebug.exe E:\archiv
e\desktops\2023..\solver\.\.\.\solver.asm

Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Scanning E:\archive\desktops\2023..\solver\.\.\.\solver.asm

0 ms    for new algo, 1 files, bufsize 4096
0 ms    for old algo, 0 files, ratio   3.474

hit any key
both files (GetF.txt and NewF.txt) remain at zero bytes, even though the 'new' version reports '1 files'.

The file "E:\archive\desktops\2023.. 2024\.\.\.\SFSudoku.asm" should be
"E:\archive\desktops\2023\05 may\5-19-2023 desktop 1\sudoku 2024\SFSudoku.asm", or similar. As shown here...
Image removed.

I can navigate there just fine with windows explorer, btw. And none of them are 0 bytes.
Image removed.

[jj2007]

When you run it with this path, what happens?

Sorry, I meant with the first part of this path, i.e. E:\archive\desktops\2023 (or similar, I can't see the complete path)

[zedd151]

Sorry, I meant with the first part of this path, i.e. E:\archive\desktops\2023

Code Select Expand

C:\Users\Administrator\Downloads\GetFilesNewDebug>GetFilesNewDebug.exe E:\archiv
e\desktops\2023


Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Scanning E:\archive\desktops\2023

0 ms    for new algo, 1 files, bufsize 4096
0 ms    for old algo, 0 files, ratio   0.6126

hit any keyboth files remain zero bytes.
I am going to do a clean install later this evening. I will run both tests afterwards.

[zedd151]

From a clean install version2 on drive C:

Code Select Expand

C:\Users\Administrator\Downloads\GetFilesNew2>GetFilesNewV2.exe C:
Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

C:

0 ms    for new algo, 1 files, bufsize 4096
21477 ms        for old algo, 16137 files, ratio   6.136e+05

C:\Users\Administrator\Downloads\GetFilesNew2>pause
Press any key to continue . . .
from clean install debug version drive C:

Code Select Expand

C:\Users\Administrator\Downloads\GetFilesNewDebug>GetFilesNewDebug.exe C:


Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Scanning C:

0 ms    for new algo, 1 files, bufsize 4096
4318 ms for old algo, 16137 files, ratio   7.080e+04

hit any keyIn both cases, NewF.txt is zero bytes, GetF.txt is appropriately sized.

For drive E:, it had the memory creep issues. So, I did not let them finish.
I am now officially done here. 

[NoCforMe]

Regarding .\.\.\ ...:
The term I was looking for is "junction point" or "reparse point". More info here.

[jj2007]

E:\archiv
e\desktops\2023

Is that the full folder path? Or could it be E:\archive\desktops\2023 whatever?

If there is a space in the path, one would need to use GetFilesNewDebug.exe "E:\archive\desktops\2023 whatever" (if you drag a file with spaces around, Windows adds the quotes).

I have no other explanation for the 0 files result

[zedd151]

Even if there were spaces in the path, your program should be able to handle that. Especially if the search path given is only the drive letter,  I.e., C:, D:, E:, .....

Anyway, I am copying the entire contents of my E: partition, file by file, folder by folder, to another drive.
Image removed.

 I am thinking that the file system is compromised on the E: partition somehow. Probably a good time to delete some old test code and other junk (unusable projects, etc) , that will probably never be used again. 

As a side note, I am quite sure that there are no junction points, reparse points, symbolic links, etc. on my E: partition. Windows does that with some files/folders though, on the OS partition (winsxs for instance).

[jj2007]

476,197 files, wow. Ok, that explains perhaps the memory use. So now I am running into a conceptual issue: a Million files is not a problem for the dir command: it just dumps them all to the console. In contrast, GetFiles() creates an array of strings for further processing in memory. Which implies there will be a limit...

Even if there were spaces in the path, your program should be able to handle that.

Actually, it can handle spaces, I just checked, and it turns out it uses the complete commandline.

[daydreamer]

Because you use HD,shouldn't each tester write drive info ?
Ramdrive,ssd,physical HD,old HD or brand new HD
Would fragmented / not fragmented drive have effect on speed ?
 

[jj2007]

Yes, drive info could be useful, but it's not essential. What I really want to see is the speed difference between the old version (relying on FindFirstFile) and the new one.

[zedd151]

Less than a half million files is a small number. You wanted to test speed difference between two algos, I chose that partition for a reason. You never know how the end user will use the function, presuming you are including it in MasmBasic. So, you can't really cherry pick the easiest search path with much fewer files. I have an external drive with over 4 million files. But that would be exteremely slow to search, as it is a USB2 connection which inherently makes it slower than an internal hard drive or partition.
If it is going to be "production" code, it should be put through the wringer with various tests to ensure it is bullet proof. .

Anyway, it is clear that your new function is much faster than the old.  about 7x
[detour]
The upshot of my part in this testing, is that I have cleaned up that partition.  Removed the errant ".asm" files and associated files, got rid of some old test code, got rid of several folders that were extracted from large .zip files (I left the .zip files of course, for use when needed), and some other housekeeping chores on a couple other partitions.   So far, I have not found any corrupted files.
  Now doing housekeeping on my external drives is another matter. Too big of a task to do in one day, I'll have to put that on the back burner. lol
Side note: The partition that I cleaned had an MFT almost 800 MB. After the cleanup and formatting, and moving the files back, the MFT is now only 73 MB. Not that space is an issue these days, but thought it was worth a mention. The MFT continually grows, but doesn't shrink when files are deleted (without using external tools). Moving the files en mass to another partition, formatting then moving them back also works to reduce the MFT size. Sorry for the detour.[/detour]