Check the available storage size before starting encryption migration.

chrome/browser/ui/webui/chromeos/login/encryption_migration_screen_handler.cc

Index: chrome/browser/ui/webui/chromeos/login/encryption_migration_screen_handler.cc
diff --git a/chrome/browser/ui/webui/chromeos/login/encryption_migration_screen_handler.cc b/chrome/browser/ui/webui/chromeos/login/encryption_migration_screen_handler.cc
index 730276710f4a99c440af5c371687a4f4e74855fb..46009e1db43fdb902d65589e7596077e8b331ec8 100644
--- a/chrome/browser/ui/webui/chromeos/login/encryption_migration_screen_handler.cc
+++ b/chrome/browser/ui/webui/chromeos/login/encryption_migration_screen_handler.cc
@@ -7,6 +7,9 @@
 #include <string>
 #include <utility>
 
+#include "base/files/file_path.h"
+#include "base/sys_info.h"
+#include "base/task_scheduler/post_task.h"
 #include "chrome/browser/lifetime/application_lifetime.h"
 #include "chromeos/cryptohome/homedir_methods.h"
 #include "chromeos/dbus/cryptohome_client.h"
@@ -16,6 +19,12 @@ namespace {
 
 constexpr char kJsScreenPath[] = "login.EncryptionMigrationScreen";
 
+// Path to the mount point to check the available space.
+constexpr char kCheckStoragePath[] = "/home";

[fukino, 2017/04/10 12:08:50]

I'd like to call statvfs to a path on the stateful partition.
I assume that "/home" is mounted on the partition, but it should not be
guaranteed. (To me, it's hard to imagine that it will change in the future,
though)

More robust alternative should be adding cryptohome API to ask the remaining
space, but not sure if this use case justifies adding a new API.

WDYT?

[xiyuan, 2017/04/10 17:24:55]

I am fine with using hard-coded "/home". I am not an expert of the mount though.
You might want to double check with Gwendal to make sure this is the correct one
for checking space needed for migration.

[fukino, 2017/04/10 23:04:58]

I call statvfs on "/home" to check the available space in the stateful partition
before sign in.
I assume that we can expect that "/home" is mounted on the stateful partition.
Do you have any concerns on this approach? Should I add cryptohome API to check
the available space?

+
+// The minimum size of available space to start the migration.
+constexpr int64_t kMinimumAvailableStorage = 10LL * 1024 * 1024;  // 10MB
+
 // JS API callbacks names.
 constexpr char kJsApiStartMigration[] = "startMigration";
 constexpr char kJsApiSkipMigration[] = "skipMigration";
@@ -59,10 +68,7 @@ void EncryptionMigrationScreenHandler::SetUserContext(
 }
 
 void EncryptionMigrationScreenHandler::SetShouldResume(bool should_resume) {
-  if (current_ui_state_ == INITIAL && should_resume) {
-    // TODO(fukino): Wait until the battery gets enough level.
-    StartMigration();
-  }
+  should_resume_ = should_resume;
 }
 
 void EncryptionMigrationScreenHandler::SetContinueLoginCallback(
@@ -70,6 +76,25 @@ void EncryptionMigrationScreenHandler::SetContinueLoginCallback(
   continue_login_callback_ = std::move(callback);
 }
 
+void EncryptionMigrationScreenHandler::SetupInitialView() {
+  if (should_resume_) {
+    // TODO(fukino): Handle the following case.

[xiyuan, 2017/04/10 17:24:55]

Why not always start with CheckAvailableStorage() and move the |should_resume_|
check to call StartMigration() in OnGetAvailableStorage() ?

[fukino, 2017/04/12 01:43:05]

You are right.
It is much simpler to always start with CheckAvailableStorage().
I updated the code to do so, and in |should_resume_| situation, I replaced
"Skip" button with "Restart" button since we can not sign in to the current
user's session.
(Showing sign-in screen instead of Restart should be better, but I chose
"Restart" for now for simplicity for a very rare situation.)

+    //
+    // 1) User A starts migration, but shuts down the device during migration.
+    // 2) User B signs in to the device and fills the storage.
+    // 3) User A signs in. The user needs resume the migration, but no space.
+    //
+    // If we don't handle this case, the user A's profile can be wiped due to
+    // the failure of migration in step 3. (or B's profile can be wiped by
+    // periodical disk cleanup.)
+    // By providing "Sign out" option for this situation, we might be able to
+    // avoid profile removal.
+    StartMigration();
+  } else {
+    CheckAvailableStorage();
+  }
+}
+
 void EncryptionMigrationScreenHandler::DeclareLocalizedValues(
     ::login::LocalizedValuesBuilder* builder) {}
 
@@ -93,7 +118,6 @@ void EncryptionMigrationScreenHandler::RegisterMessages() {
 }
 
 void EncryptionMigrationScreenHandler::HandleStartMigration() {
-  // TODO(fukino): Wait until the battery gets enough level.
   StartMigration();
 }
 
@@ -124,6 +148,26 @@ void EncryptionMigrationScreenHandler::UpdateUIState(UIState state) {
   CallJS("setUIState", static_cast<int>(state));
 }
 
+void EncryptionMigrationScreenHandler::CheckAvailableStorage() {
+  base::PostTaskWithTraitsAndReplyWithResult(
+      FROM_HERE,
+      base::TaskTraits().MayBlock().WithPriority(
+          base::TaskPriority::USER_VISIBLE),
+      base::Bind(&base::SysInfo::AmountOfFreeDiskSpace,
+                 base::FilePath(kCheckStoragePath)),
+      base::Bind(&EncryptionMigrationScreenHandler::OnGetAvailableStorage,
+                 weak_ptr_factory_.GetWeakPtr()));
+}
+
+void EncryptionMigrationScreenHandler::OnGetAvailableStorage(int64_t size) {
+  if (size < kMinimumAvailableStorage) {
+    UpdateUIState(NOT_ENOUGH_STORAGE);
+  } else {
+    // TODO(fukino): Check the battery level.
+    UpdateUIState(READY);
+  }
+}
+
 void EncryptionMigrationScreenHandler::StartMigration() {
   DBusThreadManager::Get()
       ->GetCryptohomeClient()