Storage view does not count correctly space used by app

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

(we use the space info from the click manifest)

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.

@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

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
>

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

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."

Move to 12 as would like to see this fixed

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