<div dir="ltr">A few issues:<div>* Browse already have a mechanism to remove the temporary downloaded files,</div><div>we need to know what is wrong [1]. </div><div>* Temporary directories are shared between instances, if we remove temporary directories </div><div>at activity start or stop, we need check if there are other instances of the activity running.</div><div><br></div><div>Gonzalo</div><div><br></div><div>[1] <a href="https://github.com/sugarlabs/browse-activity/blob/master/downloadmanager.py#L289">https://github.com/sugarlabs/browse-activity/blob/master/downloadmanager.py#L289</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">G'day Sam,<br>
<br>
The pull request I've made will handle a preserved .sugar directory on<br>
upgrade by deleting the directories the next time an activity is<br>
started, as well as when an activity is closed or crashes.<br>
<br>
Implemented in the shell, or sugar-launch, or activity to activity<br>
start, on behalf of the activity being started.<br>
<br>
That's option 2 and 4 from my previous post.<br>
<br>
Are there any activities that improperly depend on retaining data in<br>
these directories?<br>
<span class=""><br>
On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote:<br>
> Thanks for the good analysis James!<br>
><br>
> I don't think that deleting on startup is an optimal idea. It is<br>
> counter-intuitive that the user must open every activity on their computer when<br>
> they want to reclaim space. It is also bad in the case of infrequently used<br>
> activities.<br>
><br>
> I think that a multi-pronged approach would be better. As you noted, the<br>
> activity clearing their tmp and instance folders themselves is optimal (option<br>
> 3). I agree with this, as it takes load out of the shell process and means<br>
> that the filesystem space is reclaimed a quick as possible.<br>
><br>
> However, to deal with the issue of crashing or non-sugar3 activities, we could<br>
> also delete ALL tmp and instance folders during the shutdown process (after<br>
> stopping all activities is successful). In the best case, this should be as<br>
> quick as running ls on all of the folders (which is quick right?). It also<br>
> helps users who are upgrading their system and preserving their .sugar<br>
> directory. The shell does also not need to be responsive during shutdown.<br>
><br>
> Thanks,<br>
> Sam<br>
><br>
</span><span class="">> On Wed, Jan 20, 2016 at 1:50 PM, James Cameron <[1]<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>> wrote:<br>
><br>
> The API documentation was wrong, and has been edited.<br>
><br>
</span>> [2]<a href="https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API</a><br>
<div><div class="h5">><br>
> Rainbow did delete instance and tmp. Sugar did not.<br>
><br>
> Rainbow has not been in OLPC OS for some time. (/etc/olpc-security<br>
> must exist, /usr/bin/rainbow-run must be executable).<br>
><br>
> Rainbow is not in other builds that use Sugar.<br>
><br>
> Sugar activities that were coded for Rainbow, and against this<br>
> documentation, will leave an instance and tmp directory on the<br>
> system. Every activity.<br>
><br>
> Sugar must delete both directories.<br>
><br>
> The next question is when?<br>
><br>
> 0. on reinstall of OLPC OS, or reboot of SoaS,<br>
><br>
> This is what we do at the moment.<br>
><br>
> 1. on Sugar start,<br>
><br>
> cleanup_temporary_files in sugar:src/jarabe/main.py might be extended,<br>
> so that Sugar starts up and deletes the directories.<br>
><br>
> Disadvantage is a small delay during Sugar start, the need to iterate<br>
> over the bundle ids, and which list of bundles to use.<br>
><br>
> 2. on activity start,<br>
><br>
> The activity factory module function get_environment() in<br>
> sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py<br>
> might be extended to delete first, before making the directories.<br>
><br>
> Disadvantage is a small delay during activity start.<br>
><br>
> 3. on activity close<br>
><br>
> In the Activity class method _complete_close() in<br>
> src/sugar3/activity/activity.py we might delete the directories as the<br>
> activity is closing.<br>
><br>
> Disadvantage is that an activity that crashes won't delete the<br>
> directories.<br>
><br>
> Advantage is that any waste will be cleaned as soon as possible.<br>
><br>
> 4. on activity close in shell<br>
><br>
> Disadvantage is that Sugar may be momentarily unresponsive when an<br>
> activity closes or crashes.<br>
><br>
> Can we work toward a consensus?<br>
><br>
> My preference is on activity start, since that is the last time it<br>
> must be done to be consistent with the design intent. Are you<br>
> registered on github?<br>
><br>
> On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote:<br>
> > At a workshop I am giving in Rwanda, an XO got 'Journal Full'. It<br>
> > turns out that the Browse instance folder was using 1.2GB of store.<br>
> ><br>
> > The low-level API says:<br>
> ><br>
> > $SUGAR_ACTIVITY_ROOT/instance/<br>
> > This directory is used similar to a /var/tmp directory, being<br>
> > backed by flash rather than by RAM. It is unique per instance. It is<br>
> > used for transfer to and from the datastore (see keeping and<br>
> > resuming). This directory is deleted when the activity exits<br>
> > (specifically, as soon as all children of the activity's first<br>
> > process die)<br>
> ><br>
> > However, apparently in 0.106 this directory is not being deleted.<br>
> ><br>
> > Tony<br>
><br>
> --<br>
> James Cameron<br>
</div></div>> [3]<a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
> _______________________________________________<br>
> Sugar-devel mailing list<br>
> [4]<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
> [5]<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
><br>
> References:<br>
><br>
> [1] mailto:<a href="mailto:quozl@laptop.org">quozl@laptop.org</a><br>
> [2] <a href="https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API</a><br>
> [3] <a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
> [4] mailto:<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
> [5] <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<div class="HOEnZb"><div class="h5"><br>
> _______________________________________________<br>
> Sugar-devel mailing list<br>
> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
<br>
--<br>
James Cameron<br>
<a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Gonzalo Odiard<br><br></div>
</div>