New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 640504 link

Starred by 4 users

Issue metadata

Status: Verified
Owner:
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Available space in Files app and Storage manager are inconsistent.

Project Member Reported by fukino@chromium.org, Aug 24 2016

Issue description

Version: ToT
OS: Chrome OS

What steps will reproduce the problem?
(1) Open Files app and navigate to Downloads
(2) Press 3-vertical-dot button at top-right corner
(3) Check the remaining space shown on the menu
(4) Open Storage manager by chrome://settings/storage
(5) Check the available space shown on the screen.

What is the expected output?
The space shown in (3) and (5) are consistent.

What do you see instead?
They are not.
In the attached screenshot, Available space shown in Storage manager is 293 MB, but Files app says "0 bytes left".

Please use labels and text to provide additional information.

 
Screenshot 2016-08-24 at 5.18.35 PM.png
98.3 KB View Download

Comment 1 by fukino@chromium.org, Aug 24 2016

Description: Show this description

Comment 2 Deleted

Comment 3 by fukino@chromium.org, Aug 24 2016

Storage manager simply shows |real remaining size|.
Files app shows the remaining size using following math.
|real remaining size| + |evictable cache size| - 512MB.

|evictable cache size| is added because users will be able to use the space by automatic cache eviction.
512MB is subtracted because 512MB is the minimum space. If the real remaining size is 800MB, the actual margin users can use is (800 - 512) = 288MB.

By introducing Storage manager, it becomes confusing.
I think following options are better now.
1) In Files app, simply show |real remaining size|. It is same as "Available" in Storage manager.
2) In Files app, show |real remaining size| + |evictable cache size|. It is basically same as "Avalable" + "Offline files" in Storage manager.

Hiro, WDYT?
Cc: rookrishna@chromium.org dhadd...@chromium.org
filled same issue here https://buganizer.corp.google.com/issues/31042070
Consistency is a good thing. Let's do this: 

1. Change the copy in Files app from xxxGB left to Available
2. Use the same math in Files app as we do in storage management for available space
Project Member

Comment 6 by bugdroid1@chromium.org, Aug 25 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e23227790211a07cbb31d711a2a52e313f8fc0d1

commit e23227790211a07cbb31d711a2a52e313f8fc0d1
Author: fukino <fukino@chromium.org>
Date: Thu Aug 25 09:17:10 2016

Make chrome.fileManagerPrivate.getSizeStat return actual available space for Downloads.

getSizeStat() for Downloads used to return
|actual available space| + |evictable Drive cache| - 512MB.
To be consistent with Storage manager (chrome://settings/storage), getSizeStat()
should simplly return |actual available size|.

BUG= 640504 
TEST=manually compared the avaiable space in Files app and Storage manager.

Review-Url: https://codereview.chromium.org/2274003004
Cr-Commit-Position: refs/heads/master@{#414371}

[modify] https://crrev.com/e23227790211a07cbb31d711a2a52e313f8fc0d1/chrome/app/chromeos_strings.grdp
[modify] https://crrev.com/e23227790211a07cbb31d711a2a52e313f8fc0d1/chrome/browser/chromeos/extensions/file_manager/private_api_file_system.cc
[modify] https://crrev.com/e23227790211a07cbb31d711a2a52e313f8fc0d1/chrome/browser/chromeos/extensions/file_manager/private_api_file_system.h

Comment 7 by fukino@chromium.org, Aug 25 2016

Status: Fixed (was: Started)
Thanks Hiro, Jonny!
The change described in c#5 has landed.
Closing...
Labels: VerifyIn-54
Now storage space is same in Files app and Storage manager.

But its not consistent with settings-> android preference-> storage.
Verified on Chrome:54.0.2840.10/Chromeos:8743.8.0.

Screenshot 2016-09-02 at 1.59.05 PM.png
290 KB View Download
Is this going into M53?
They don't match for me in latest 8530.84.0
Screenshot 2016-09-13 at 3.55.46 PM.png
74.7 KB View Download
I suppose it's not going to be merged to M53 as it is P2.
mitsuji@, could you double check? Should we ask a merge for M53?

Comment 12 by mitsuji@google.com, Sep 14 2016

Hmm, that's a shame, I thought this change was merged into M53. At this point it's a bit late IMO, can we treat this as a bug fix in M54? 
Labels: M-54
M54 already has the fix. (The fix landed on the M54 branch cut day)
Let me keep this as Fixed and M-54 label for this.

Comment 14 by son...@google.com, Oct 4 2016

Status: Verified (was: Fixed)
Verified on build 8861.0.0

Sign in to add a comment