Forum > Discussion Forum
Working with App_info.xml and extraneous.
Josef W. Segur:
I've been digging through the BOINC source, and am more than 90% certain of the following:
1. Download file verification uses either a signature or an MD5 checksum. If a file is considered an application file it wants the signature. If it's just a project file, the MD5 is used.
2. If a file is listed in a <file_ref> within an <app_version> it is automatically considered an application file, otherwise it's not.
3. If an application file <file_ref> came from an app_info.xml, BOINC doesn't delete the file even if it cannot be used.
4. The "cannot accept" means at that point BOINC won't link that app_version to tasks. That could cause freshly downloaded tasks to be deleted.
My conclusion is the <md5_cksum> entries aren't needed in the app_info.xml listed here, though if you had the AUTHORS, etc. they'd need those entries. They aren't protected by a <file_ref>.
=======================
Opinion: I think for now we should drop the idea of automatic downloads of individual files from the project. If a host doesn't have the right stuff to use a full set of Lunatics apps, and doesn't already have the required stock files, the installer should not complete. Maybe it would be possible to advise the user what's lacking, maybe just say the installer can't do what has been requested and advise where to ask for help. The basic advice would be to get the stock applications running, then try the installer again.
Joe
Pappa:
Joe et al
Go look at this. It appears with "progress" Boinc has gotten smarter in attempting to recover from corrupt files. It shows a Lunatics App that Boinc was attemting D/L from Seti.
--- Quote from: Pappa on 16 May 2009, 02:01:11 pm ---Okay, in the NC forum, a machine that had a corrupt/missing Optimized App attempted to download the missing file.
http://setiathome.berkeley.edu/forum_thread.php?id=53645&nowrap=true#895297
--- End quote ---
Josef W. Segur:
--- Quote from: Pappa on 17 May 2009, 12:16:20 am ---Joe et al
Go look at this. It appears with "progress" Boinc has gotten smarter in attempting to recover from corrupt files. It shows a Lunatics App that Boinc was attemting D/L from Seti.
...
--- End quote ---
That's not new, and it isn't due to a corrupt file but a missing file. Once a file with <file_ref> from an app_info.xml is in the project folder, the core client doesn't check it other than to see if it is there. If a missing file is linked to some work, the core client makes a desperate attempt to download it from the project since that's the only known base URL. It's more a bug than a feature.
Joe
Raistmer:
Is it possible to use current app_info.xml structure to assign different versions to different apps with the same plan?
I.e. is it possible to have both SSE4.1 and SSSE3x apps installed under 6.03 and 6.04 versions (for example) ?
Richard Haselgrove:
--- Quote from: Raistmer on 17 May 2009, 06:22:50 am ---Is it possible to use current app_info.xml structure to assign different versions to different apps with the same plan?
I.e. is it possible to have both SSE4.1 and SSSE3x apps installed under 6.03 and 6.04 versions (for example) ?
--- End quote ---
Yes, I think it is - we did that with the first (awkward) AP transition from v4.35 to v5.00 last November.
But the problem is, all new work fetched is assigned to the highest available version number - so in your example, once any v6.03 work currently in the cache is completed, the SSE4.1 app would never be used again unless you went through the 'rebranding' exercise.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version