Re: [Sugar-devel] activity instance directory

[James Cameron]

Thanks, I await your testing of my pull request.

On Thu, Jan 21, 2016 at 07:13:47AM +0200, Tony Anderson wrote:
> Hi, James
> 
> It would seem the correct solution is to have Sugar implement
> the procedure specified in the 'low level activity'. The instance folder
> should be cleared when the activity quits. If an activity needs longer
> persistence, it can put the file in the data folder and then manage it.
> 
> The issue is storage. An XO-1 has 1GB total. When the available storage
> falls below 50MB, the "Journal is Full" modal dialog is shown (a non
> sequitor since the
> Journal may not be the culprit). Sugar provides no tools to the user to
> determine the cause of the problem or to deal with it. In my experience,
> deployments reflash losing all Journal data.
> 
> Tony
> 
> On 01/21/2016 02:19 AM, James Cameron wrote:
> >We can't know what is wrong, because the logs aren't available, but my
> >guess is one or more downloads were started, and the total for the day
> >reached 1.2 Gb.  That's all it takes.
> >
> >Downloads in progress are invisible to a user of Browse, so it is an
> >easy mistake to make.
> >
> >For data shared between instances, we must use the data directory, not
> >the instance or tmp directories, so any activity that does as you say
> >must be fixed.
> >
> >I've done some tests.
> >
> >During download, instance directory has a file .goutputstream-* which
> >will be cleared by _cleanup_temp_files in webactivity.py if Browse is
> >started the day after the files were modified.  Browse does not remove
> >these files on the day.  The code you refer to is only used when
> >Browse is still running, and only for the destination path files, not
> >the gio files referred to in #3973.
> >
> >Browse correctly uses data directory for places.db and gecko
> >certificates and cookies.
> >
> >So the scenario that Tony describes is likely to cause the problem.
> >
> >Also, it won't be fixed by stopping and starting Browse.
> >
> >But it will be fixed by my patch in combination with stopping and
> >starting Browse.
> >
> >On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote:
> >>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] [1]https://github.com/sugarlabs/browse-activity/blob/master/
> >>downloadmanager.py#L289
> >>
> >>On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]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][3]qu...@laptop.org>
> >> wrote:
> >> >
> >> > The API documentation was wrong, and has been edited.
> >> >
> >> > [2][4]https://wiki.sugarlabs.org/go/Development_Team/
> >> Low-level_Activity_API
> >> >
> 

Re: [Sugar-devel] activity instance directory

[Tony Anderson]

Hi, James

It would seem the correct solution is to have Sugar implement
the procedure specified in the 'low level activity'. The instance folder
should be cleared when the activity quits. If an activity needs longer
persistence, it can put the file in the data folder and then manage it.

The issue is storage. An XO-1 has 1GB total. When the available storage
falls below 50MB, the "Journal is Full" modal dialog is shown (a non 
sequitor since the

Journal may not be the culprit). Sugar provides no tools to the user to
determine the cause of the problem or to deal with it. In my experience,
deployments reflash losing all Journal data.

Tony

On 01/21/2016 02:19 AM, James Cameron wrote:

We can't know what is wrong, because the logs aren't available, but my
guess is one or more downloads were started, and the total for the day
reached 1.2 Gb.  That's all it takes.

Downloads in progress are invisible to a user of Browse, so it is an
easy mistake to make.

For data shared between instances, we must use the data directory, not
the instance or tmp directories, so any activity that does as you say
must be fixed.

I've done some tests.

During download, instance directory has a file .goutputstream-* which
will be cleared by _cleanup_temp_files in webactivity.py if Browse is
started the day after the files were modified.  Browse does not remove
these files on the day.  The code you refer to is only used when
Browse is still running, and only for the destination path files, not
the gio files referred to in #3973.

Browse correctly uses data directory for places.db and gecko
certificates and cookies.

So the scenario that Tony describes is likely to cause the problem.

Also, it won't be fixed by stopping and starting Browse.

But it will be fixed by my patch in combination with stopping and
starting Browse.

On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote:

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] [1]https://github.com/sugarlabs/browse-activity/blob/master/
downloadmanager.py#L289

On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]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][3]qu...@laptop.org>
 wrote:
 >
 > The API documentation was wrong, and has been edited.
 >
 > [2][4]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 

Re: [Sugar-devel] activity instance directory

[James Cameron]

We can't know what is wrong, because the logs aren't available, but my
guess is one or more downloads were started, and the total for the day
reached 1.2 Gb.  That's all it takes.

Downloads in progress are invisible to a user of Browse, so it is an
easy mistake to make.

For data shared between instances, we must use the data directory, not
the instance or tmp directories, so any activity that does as you say
must be fixed.

I've done some tests.

During download, instance directory has a file .goutputstream-* which
will be cleared by _cleanup_temp_files in webactivity.py if Browse is
started the day after the files were modified.  Browse does not remove
these files on the day.  The code you refer to is only used when
Browse is still running, and only for the destination path files, not
the gio files referred to in #3973.

Browse correctly uses data directory for places.db and gecko
certificates and cookies.

So the scenario that Tony describes is likely to cause the problem.

Also, it won't be fixed by stopping and starting Browse.

But it will be fixed by my patch in combination with stopping and
starting Browse.

On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote:
> 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] [1]https://github.com/sugarlabs/browse-activity/blob/master/
> downloadmanager.py#L289
> 
> On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]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][3]qu...@laptop.org>
> wrote:
> >
> >     The API documentation was wrong, and has been edited.
> >
> >     [2][4]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 

Re: [Sugar-devel] activity instance directory

[James Cameron]

Tony,

Please test this pull request;
https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/306

"Remove Rainbow, clear activity instance/ and tmp/

Sugar depended on Rainbow for clearing the activity instance/ and tmp/
directories.  But Rainbow is no longer used downstream.

 - remove support for Rainbow,

 - clear the contents of instance/ and tmp/ on start and stop,

 - avoid race when creating directories; don't check they exist before
   we create.

https://bugs.sugarlabs.org/ticket/4931

On Wed, Jan 20, 2016 at 01:50:31PM +1100, James Cameron wrote:
> The API documentation was wrong, and has been edited.
> 
> 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
> http://quozl.netrek.org/

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] activity instance directory

[Sam P.]

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  wrote:

> The API documentation was wrong, and has been edited.
>
> 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
> http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] activity instance directory

[James Cameron]

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

Re: [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  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 

Re: [Sugar-devel] activity instance directory

[James Cameron]

The API documentation was wrong, and has been edited.

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
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel