Just curious how session files are managed on the client. I have various computers who store old sessions, and re-download them whenever I manually delete them.

As of writing this, the only active session on burp is 993...

Computer #1 : Boinc 6.2.14 - No sessions downloaded.
Computer #2 : 6.10.17 - Sessions 950, 1009, 1020.
Computer #3 : 6.10.17 - joined recently / never crunched. Has sessions 996 and 993.

It looks like the session files are re-downloaded if the client has worked on tasks in the past. Even though the session is complete. Except for Computer #1 which is 6.2.14 (could it be a "bug" with the 6.10.17 clients?).

I suppose a timely deletion of workunits/results would handle the problem, but not downloading if the session is complete could be a quick fix(?). It would (at least) allow me to clean up my client without re-downloading.

I quickly looked at the development site and didn't see anything related. Can you add the devel link to the burp web menu (under "Other?")?

Thanks and keep up the excellent work!

Yes, the BOINC sticky files have always been a little funny. In theory what it should do is to download the files when you are rendering and then leave them on the host (not redownload them unless you are rendering them again). This allows the client to re-use the same files between workunits and sessions without fetching them for each workunit.

There's a workaround on the server that will ask hosts to delete files that haven't been used for a (really) long time. Additionally BOINC will delete them once it hits the disk limits specified in your host's preferences.

I quickly looked at the development site and didn't see anything related. Can you add the devel link to the burp web menu (under "Other?")?

Sure, the "Help us code" menu item now points to the development platform.

There's a workaround on the server that will ask hosts to delete files that haven't been used for a (really) long time. Additionally BOINC will delete them once it hits the disk limits specified in your host's preferences.

Yeah, would be nice to have such a thing on BURP too, Einstein uses this thing always to delete files, which are not more used.
I mostly do a regular check of my BURP folder, when it grows too big of unused sessions, I delete them. ORE (Renderfarm.fi) unfortunately has the same problem, I forgot about that and as I watched recently I had over 800 MB in the folder... ;-)

Tips from my experiences:
The re-download of older sessions either can be prevented by editing the client_state.xml, which contains all ever transferred files (but that needs a little knowledge), or by cancelling it the time they are redownloaded(!), the client remembers this then and it shouldn't occur that next time of starting BOINC/BURP the session files are downloaded again.

---

Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg
My BOINC-Stats

If the disk limits will auto-delete the old sessions, I suppose it's ok. I was worried about refusing work due to space limits (mainly at ORE).

Thanks DoctorNow for the tip about aborting the transfer. I'll try that too.

Deleting old results from the server seems to work. BURP is pretty clean (~5K) while ORE seems cluttered (~180K). Once this gets automated(?) it should clear things up.

Thanks

Deleting old results from the server seems to work. BURP is pretty clean (~5K) while ORE seems cluttered (~180K). Once this gets automated(?) it should clear things up.

This was automated for completed sessions fairly recently and the patch deployed on both the main BURP project as well as the clones. Failing sessions will stay in the table until they can be looked at by an admin and then removed.

It looks like the session files are re-downloaded if the client has worked on tasks in the past. Even though the session is complete.

This should now have changed. The client will keep recent files and libraries but will delete old ones during scheduler requests.