Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD A good lesson: If %@UNIQUE[] fails, use %@UNIQUEX[] instead!

Jul
532
10
I didn’t believe it until I saw it.

Yesterday and last night, I was running a script in many thousands of folders (a batch LRC/SRT->to-TXT converter I wrote, python-wrapped-in-BAT-files). The total run took almost 24 hours.

It was working fine when I went to sleep.
When I woke up, my set-tmp-file bat that sets %TMPFILE to a unique filename in the %TEMP folder started failing and throwing errors.

I have a theory that %@UNIQUE croaked because there are too many files in my %TEMP% folder.

I just checked and there are 99,414 files totaling 3G. With the exception of about 100 of them, all 99,000 were generated in the past 3 weeks. So it is indeed a NEW thing for me to have these many files in %TEMP% . . I do believe My autoexe.bat wipes it every reboot but a 100 or so from 2019 are "stuck" in read only mode and I haven’t cared enough to manually delete them because my SSD still has 189G free and it’s a bit too sisyphian for me.

To test this theory, i made a temp.Borked folder and moved as many files as I could into there (move /s . ..\temp.bork). It ended up decreasing files from 99,414 to 121.

Voila! %@UNIQUE is working now!

Okay. So. Verified. %@UNIQUE[] croaks if too many files are in the folder. If I had to guess, I’d guess there’s a limit of 32,767 or 65,536.

1735648768679.webp
 
Wow!!!! Had no clue about UNIQUEX!!!!!

Maybe the error message should mention this. Might save you answering threads hehe.

I guess UNIQUEX is your own implementation without the bugs of Windows???? Makes sense! Thanks!!
 
If only Microsoft could be this responsive!
 
Back
Top