Prime95: INI_FILE settings limited to 80 characters

[sp00n]

This is taken from the source file for version 30.3b6.
In the common.c file the various INI settings are defined as e.g.

IniGetString (INI_FILE, "local.ini", LOCALINI_FILE, 80, LOCALINI_FILE);
IniGetString (INI_FILE, "worktodo.ini", WORKTODO_FILE, 80, WORKTODO_FILE);
IniGetString (INI_FILE, "results.txt", RESFILE, 80, RESFILE);

which limits the value to 80 characters.

I was trying to write the log file to a different directory than where the binary file and the prime.txt/local.txt are, and if you're using a longer file name (e.g. by adding the date and time) or a longer directory name, these 80 characters can be exceeded, which in turn cuts off the name of the file that is generated in the provided directory.

Example:
Directory of the prime95.exe: D:\Benchmarking\Prime95\30.3b6\binaries\
Directory of results.txt file: D:\Benchmarking\Prime95\30.3b6\logs\
Name of results.txt: Prime95_results_2020-12-31_23_59_59_FFT_248-8192.txt

Expected file name:
D:\Benchmarking\Prime95\30.3b6\logs\Prime95_results_2020-12-31_23_59_59_FFT_248-8192.txt

Actual file name (cut off after 80 characters):
D:\Benchmarking\Prime95\30.3b6\logs\Prime95_results_2020-12-31_23_59_59_FFT_248


Is there any particular reason why there's a limit to 80 characters and not to ~260 characters like Windows supports?

I seem to have been able to work around this by setting the WorkingDir= directive to one level above the directory where the .exe is located then setting prime.ini=, local.ini= and results.txt= as a relative path from that directory.
It appears to be working, but it seems unnecessarily complicated.

These are the resulting entries in the prime.txt, of course, they're only examples.
(I also find it a bit weird that you can set the file name for the prime.ini/txt in that exact prime.txt.)

WorkingDir=D:\Benchmarking\Prime95\30.3b6
prime.ini=binaries\prime.txt
local.ini=binaries\local.txt
results.txt=logs\Prime95_results_2020-12-31_23_59_59_FFT_248-8192.txt

So I'd suggest to change the 80 character limit to something higher in a future release so that these kind of workarounds aren't required anymore.

(Also, for more than just stress testing, you'd probably have to modify the other settings as documented in undoc.txt to the relative path as well.)

[ixfd64]

The 80-character limit is a relic of a bygone era when most computer screens could not display more than 80 columns. I agree it's no longer relevant in this day and age.

[Prime95]

Prime95 is a relic, There are 8.3 limits in some of the code. I'll boost the limits you mentioned in 30.5.

[kriesel]

Originally Posted by Prime95

Prime95 is a relic, There are 8.3 limits in some of the code. I'll boost the limits you mentioned in 30.5.

It would be great if the obfuscated-exponent filename consequences of that residual 8.3-ness went away.
Quick, what exponent does file pA852841.residues relate to? pA851779.proof?

[LaurV]

Originally Posted by kriesel

Quick, what exponent does file pA852841.residues relate to? pA851779.proof?

Plus one for that! Well spotted! May George be healthy and have free time in the future, so he fix all those relics...

[kriesel]

Also p8U82187 and related .bu* (dated today and yesterday, produced by prime95 v30.4b9 LL DC of M55882187)
There are p(clear 9 digit exponent) files produced in the same folder during the same time frame, from other work types from other workers on that instance.

pA853833.* from PRP-CF of M10853833

(and more examples like the above)

[chalsall]

Originally Posted by LaurV

Plus one for that! Well spotted! May George be healthy and have free time in the future, so he fix all those relics...

+1!

Thanks, George!

[sp00n]

Originally Posted by Prime95

Prime95 is a relic, There are 8.3 limits in some of the code. I'll boost the limits you mentioned in 30.5.

Great, thanks.

[LaurV]

Originally Posted by kriesel

Also p8U82187 of M55882187
pA853833.* from PRP-CF of M10853833
(and more examples like the above)

To be fair, we know (and always knew) how to decode those, there is some explanation in those .txt files sent with P95, which no one reads them ever. But it would be indeed wonderful if George fix the checkpoint names and temp file names, to something more clear and palatable, considering the new invention called "long file names".
We wouldn't mind zero-filled names to 9 positions, so we can sort them properly in the folder when there are different numbers of digits (edit: like for example M098765432_blah_blah.bkp, to be sorted before M123456789_blah_blah.bkp, and not M98765432_blah_blah.bkp).

[kriesel]

The readme.txt file list section seems to indicate they'll have alpha first char, numeric ASCII for exponent. But the 7 N's don't fit even current DC exponents.

cNNNNNNN,cNNNNNNN.buN    Intermediate files produced during certification runs.
pNNNNNNN,pNNNNNNN.buN    Intermediate files produced by prime95.exe to resume computation where it left off.
pNNNNNNN.residues    Large intermediate file produced during PRP test for constructing a PRP proof.
pNNNNNNN.proof        PRP proof file.
eNNNNNNN,eNNNNNNN.buN    Intermediate files produced during ECM factoring.
fNNNNNNN,fNNNNNNN.buN    Intermediate files produced during trial factoring.
mNNNNNNN,mNNNNNNN.buN    Intermediate files produced during P-1 factoring.

I didn't see an explanation for the leading or embedded alpha characters.
Nothing relevant to that found searching readme, whatsnew, or undoc, for "file" or "8.3".
Where's it to be found?

[Prime95]

Originally Posted by kriesel

Where's it to be found?

The usual answer: dig into C code.