[Sugar-devel] activity instance directory

[Gonzalo Odiard]

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 <quozl at 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]quozl at 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 at lists.sugarlabs.org
> >     [5]http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> > References:
> >
> > [1] mailto:quozl at laptop.org
> > [2]
> https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> > [3] http://quozl.netrek.org/
> > [4] mailto:Sugar-devel at lists.sugarlabs.org
> > [5] http://lists.sugarlabs.org/listinfo/sugar-devel
>
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> --
> James Cameron
> http://quozl.netrek.org/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Gonzalo Odiard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160120/0671c163/attachment.html>