You can find a lot of discussion over the last few years in Number Crunching about the "finish file present too long" error, but here's a synopsis.

Great write-up, Jeff, and much appreciated that you took the time to do so. Makes perfect sense, and I've sure seen both the need and the havoc associated with such "token files" over the years, in other projects.
I've barely begun to dig into file structures, but then again I never expected (or wanted) to be writing anything that would require such info. Anyway, if it will reduce the error, I'm all for it. As noted elsewhere, those files will now be nuked immediately before client restart.
Thanks again, Jim...

---

A "boinc_finish_called" file is an empty file that's written to a task's slot directory by the science application at (or near) the end of processing for the task.

Just for completeness, for the last couple of years the file hasn't had to be empty. Normally, it will simply contain 0, to say 'everything's normal, no problems to report': but it can be used by the application developer to report errors or problems back to the user, optionally as a 'notice' which stands a better chance of getting the user's attention.

None of that detracts from the cleanup suggestions being discussed here, which sound safe and sensible.

None of that detracts from the cleanup suggestions being discussed here, which sound safe and sensible.

Thanks, Richard. Appreciate the confirmation here ...

---

A "boinc_finish_called" file is an empty file that's written to a task's slot directory by the science application at (or near) the end of processing for the task.

Just for completeness, for the last couple of years the file hasn't had to be empty. Normally, it will simply contain 0, to say 'everything's normal, no problems to report': but it can be used by the application developer to report errors or problems back to the user, optionally as a 'notice' which stands a better chance of getting the user's attention.

None of that detracts from the cleanup suggestions being discussed here, which sound safe and sensible.

Thanks, Richard. I guess I've only seen the file as an empty, zero length one. I also didn't remember seeing BOINC actually trying to read the file. I mainly remembered it polling all the slots every 10 seconds to see if any finish files existed. However, once again going back to an old Process Monitor log, I now see that it does actually read the file, empty or not. In fact, it appears to read it 3 times!

7:36:22.8757895 PM	Lunatics_x41zc_win32_cuda50.exe	3108	CreateFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	SUCCESS	Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created
7:36:22.8761910 PM	Lunatics_x41zc_win32_cuda50.exe	3108	CloseFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	SUCCESS	
7:36:23.8051144 PM	boinc.exe	1484	CreateFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	SUCCESS	Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
7:36:23.8051611 PM	boinc.exe	1484	ReadFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	END OF FILE	Offset: 0, Length: 4,096
7:36:23.8051762 PM	boinc.exe	1484	ReadFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	END OF FILE	Offset: 0, Length: 4,096
7:36:23.8051842 PM	boinc.exe	1484	ReadFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	END OF FILE	Offset: 0, Length: 4,096
7:36:23.8051947 PM	boinc.exe	1484	CloseFile	C:\Documents and Settings\All Users\Application Data\BOINC\slots\11\boinc_finish_called	SUCCESS	

Well, with all the insanity going on in my life with all the projects I have to finish before winter, I have to admit that I have been remiss in updating my program on a more regular basis, but will do that this evening, and see how much better it runs using 1.02d.

Oh, and just checked the currently running GPU tasks, it looks like about 1/2 are Guppis and half aren't, but the project was down so that may mess up the mix for a while. Thanks for keeping on top of that program Jim!

---

Well, with all the insanity going on in my life with all the projects I have to finish before winter, I have to admit that I have been remiss in updating my program on a more regular basis, but will do that this evening, and see how much better it runs using 1.02d.

Oh, and just checked the currently running GPU tasks, it looks like about 1/2 are Guppis and half aren't, but the project was down so that may mess up the mix for a while. Thanks for keeping on top of that program Jim!

Thanks for the help testing, Al. Much appreciated. Jim ...

---