GetFiles test

[zedd151]

Is your E: drive extremely full?

Nope. But there are 433607 total files there, which shouldn't make a difference.
Image removed.

Memory usage keeps climbing until that dialog box pops up again.

Several images removed.

[jj2007]

Memory usage keeps climbing until that dialog box pops up again.

Interesting. The only HeapAlloc in this program is the buildup of the string array. Assuming a path has 100 bytes on average, you would need 11 million files to arrive there.

It seems there is an endless loop going on. The question is why... I will see if I can cook up a debugging version, thanks a lot for your feedback

[zedd151]

It seems there is an endless loop going on. The questions is why... I will see if I can cook up a debugging version, thanks a lot for your feedback

The problem is not exclusive to my E: drive. Using C: as a parameter, I have the same results. I get the "low on memory" dialog box again.

[jj2007]

OK, here is a test version that displays memory use and #files every 256 paths created. I am curious...

[zedd151]

Okay, on the first run with C:, it completed successfully. I did not save the results that I had in an open txt file on the desktop. There were 17000 odd files there. (I had rebooted - read further)

On subsequent runs...
E: drive:
Image removed.

C: drive:
Image removed.

I did not let this run finish, I knew the outcome. I rebooted to see if that would make a difference, but alas, every time after the first run fails.

On the first run (drive C:), it did not list the files as you see in the pngs above, but exited gracefully after displaying the results and pressing "any" key.

[zedd151]

Just for kicks, I reran the program for C: drive

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
20856 ms        for old algo, 17246 files, ratio   5.794e+05

hit any keynew algo 1 file? But nothing is in that txt file
 ratio   5.794e+05???

[jj2007]

Over 6 Million files? Almost impossible...

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

Here's what I see:

Code Select Expand

Scanning D:\Masm32
#    0,  0 MB  D:\Masm32\asmc-master\li..ter\lib\amd64\import.asm
# 1024,  0 MB  D:\Masm32\asmc-master\so..lib\src\conio\dlshow.asm
# 2048,  0 MB  D:\Masm32\asmc-master\so..\lib64\string\memcpy.asm
# 3072,  0 MB  D:\Masm32\CmdGUI\LibTmp\LibTmpFT.asm
# 4096,  0 MB  D:\Masm32\Gfa2Masm\DimRe..l\DimRecallGetFilesC.asc
# 5120,  0 MB  D:\Masm32\GmpBigNum\gmp-..ltrasparct3\addmul_1.asm
# 6144,  0 MB  D:\Masm32\Jwasm\Samples\..Ctrl\Release\AsmCtrl.dll
# 7168,  0 MB  D:\Masm32\MasmBasic\AscU..YourManifestDualBuild.rc
# 8192,  0 MB  D:\Masm32\MasmBasic\AscU..\TmpOut\PellesC_stub.asc
# 9216,  0 MB  D:\Masm32\MasmBasic\BugT..sts\InstrFast4Arrays.asc
#10240,  0 MB  D:\Masm32\MasmBasic\BugT..ol\GuiTableControlOld.rc
#11264,  0 MB  D:\Masm32\MasmBasic\Misc..HighestFrequencySort.asc
#12288,  0 MB  D:\Masm32\MasmBasic\Res\MbGui30J.asc
#13312,  0 MB  D:\Masm32\MasmBasic\Timi..mings\Shift_vs_movsx.asc
#14336,  0 MB  D:\Masm32\Members\kkurki..urkiewicz\Dialog\prog.rc
#15360,  0 MB  D:\Masm32\ObjAsm32\Code\..ode\COM\COM_Dispatch.asm
#16384,  0 MB  D:\Masm32\RichMasm\Db32\DbMap4APo.asc

484 ms  for new algo, 17401 files, bufsize 4096
2396 ms for old algo, 17399 files, ratio  4.946
Now I run it on my C: drive... finished:

Code Select Expand

42061 ms        for new algo, 68082 files, bufsize 4096
113748 ms       for old algo, 70073 files, ratio   2.704

[zedd151]

I piped the output to a text file... this is for E:
I tried one more time. Memory kept going up and up, so I aborted

All the filenames have 20h padding after the (truncated) filenames??

[zedd151]

Over 6 Million files? Almost impossible...

Yes indeedy. On E:. I only have 433607 files! On C: much less than that

Obviously we need more testers here, to ensure that this is not just another one of those ME issues.    (its a curse I have had  once or thrice before)
I attached some of the output in the post above.

[jj2007]

All the filenames have 20h padding after the (truncated) filenames??

Yes, for cosmetic reasons only.

What do these sequences mean? Do you also get them e.g. with a dir E:\archive\desktops\*.rc?

#1024,  0 MB  E:\archive\desktops\2023..ix\.\.\.\.\.\rsrc.old.rc

Btw both the new and the old algo write all files to disk as NewF.txt and GetF.txt

[zedd151]

Do you also get them e.g. with a dir E:\archive\desktops\*.rc?

I can check that later... I have other things to attend to at the moment.

[zedd151]

Do you also get them e.g. with a dir E:\archive\desktops\*.rc?

No.

I'll be back later.

[jj2007]

attached as rc.zip

Thanks. Weird, I don't have the faintest idea what's going on. Can I come over to debug it on your machine?

[zedd151]

Thanks. Weird, I don't have the faintest idea what's going on. Can I come over to debug it on your machine?

lol
I just think we need more testers. I know some of my files were an issue (those with only an extension) , but other than that, who knows???
I have been playing with this for over four hours now, time for someone else to step up and give you some other results.

[NoCforMe]

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.)