Storage view does not count correctly space used by app

Bug #1454444 reported by Ondrej Kubik
30
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
High
Alejandro J. Cura
click (Ubuntu)
Confirmed
Undecided
Unassigned
ubuntu-system-settings (Ubuntu)
Confirmed
High
Unassigned

Bug Description

When going to Settings->About phone -> Storage
Storage used per app count does not include space used by app in ~/.local/<app>/
This makes is hard to determine which app is actually eating all the storage.
It also makes whole list kinda pointless, since we can have easily app easting 1G or more and never see it in the lis.
Apps like podcast, browser, twitter can easily eat hundreds of MB without being spotted in the list.

Expected result:
space occupied by all is calculated from the size of application itself, plus data used by application under ~/.local/<app>/

tested on RTM krillin (stable/bq-aquaris.en/krillin) v22

Ondrej Kubik (ondrak)
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

thanks but shouldn't click provide those info so all clients get the correct details rather than having to reimplement it?

Changed in ubuntu-system-settings (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Sebastien Bacher (seb128) wrote :

(we use the space info from the click manifest)

Revision history for this message
Ondrej Kubik (ondrak) wrote :

I'm not expert in click manifest, but that surely cannot have something as dynamic as size of application data which do change as user uses application.
I can imagine manifest having actual path to where application data should be stored, but it still should be calculated as we enter settings->storage view. So the settings app should parse manifest and calculated space occupied by all associated directories.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@Ondrej, well, my point is that libclick could provide a function that does that, it would be a better place because other codebase might have to get the same information and a common function in the framework used would make more sense that local implementation in every software

Revision history for this message
Ondrej Kubik (ondrak) wrote : Re: [Bug 1454444] Re: Storage view does not count correctly space used by app

That makes sense and I have no preference where it should be implemented.
If there is better home for this bug, we should move it there.
I assigned this bug to Settings app since there it's visible, so it was
good starting point :)
If we create new bug please add it here, so we can track it for krillin.

On Tue, May 19, 2015 at 9:14 AM, Sebastien Bacher <email address hidden> wrote:

> @Ondrej, well, my point is that libclick could provide a function that
> does that, it would be a better place because other codebase might have
> to get the same information and a common function in the framework used
> would make more sense that local implementation in every software
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1454444
>
> Title:
> Storage view does not count correctly space used by app
>
> Status in the base for Ubuntu mobile products:
> New
> Status in click package in Ubuntu:
> New
> Status in ubuntu-system-settings package in Ubuntu:
> Incomplete
>
> Bug description:
> When going to Settings->About phone -> Storage
> Storage used per app count does not include space used by app in
> ~/.local/<app>/
> This makes is hard to determine which app is actually eating all the
> storage.
> It also makes whole list kinda pointless, since we can have easily app
> easting 1G or more and never see it in the lis.
> Apps like podcast, browser, twitter can easily eat hundreds of MB
> without being spotted in the list.
>
> Expected result:
> space occupied by all is calculated from the size of application itself,
> plus data used by application under ~/.local/<app>/
>
> tested on RTM krillin (stable/bq-aquaris.en/krillin) v22
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1454444/+subscriptions
>

Changed in canonical-devices-system-image:
assignee: nobody → Alejandro J. Cura (alecu)
importance: Undecided → High
milestone: none → backlog
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in click (Ubuntu):
status: New → Confirmed
Changed in click (Ubuntu):
assignee: nobody → Kyle Fazzari (kyrofa)
Kyle Fazzari (kyrofa)
Changed in click (Ubuntu):
assignee: Kyle Fazzari (kyrofa) → nobody
Revision history for this message
Sebastien Bacher (seb128) wrote :

Comment from https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/lp1524424/+merge/280196

"How do applications know where to save data to? They write to a well
known directory under XDG_{CACHE,CONFIG,DATA}_HOME, so use that. Count
the logs and other stuff (if that actually does happen) as in use by the
system if it's too hard to do it any other way.

From https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement:

  Applications will always have read access to their install directory
  and have write access to directories they own as determined by the XDG
  base directory specification. Specifically:
  XDG_CACHE_HOME/<APP_PKGNAME>, XDG_RUNTIME_DIR/<APP_PKGNAME>,
  XDG_RUNTIME_DIR/confined/<APP_PKGNAME> (for TMPDIR),
  XDG_DATA_HOME/<APP_PKGNAME> and XDG_CONFIG_HOME/<APP_PKGNAME>. Apps
  can discover these paths using standard APIs and appending the package
  name as defined by the 'name' field of the manifest."

Changed in ubuntu-system-settings (Ubuntu):
status: Incomplete → Confirmed
Changed in canonical-devices-system-image:
milestone: backlog → ww08-2016
Changed in canonical-devices-system-image:
milestone: ww08-2016 → 11
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

Move to 12 as would like to see this fixed

Changed in canonical-devices-system-image:
milestone: 11 → 12
Changed in canonical-devices-system-image:
milestone: 12 → 13
Changed in canonical-devices-system-image:
milestone: 13 → backlog
Revision history for this message
Andrea Simonetti (simox) wrote :

hello,
this bug affects vegeta too..
mako has never had this problem.
thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.