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