Closed Bug 802487 Opened 12 years ago Closed 12 years ago

Download gecko+gaia updates to /sdcard

Categories

(Firefox OS Graveyard :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED DUPLICATE of bug 785124
blocking-basecamp +

People

(Reporter: cjones, Assigned: fabrice)

References

Details

It seems that we're currently downloading them to /data/local/tmp, but a full or not-well-compressed update will consume a significant % of the data partition. For the same reason we download FOTA updates to /sdcard, we should download gecko/gaia updates there too.
Per comment #1 moving over to Boot2Gecko
Component: Application Update → General
Product: Toolkit → Boot2Gecko
I'm starting to take a look at this. We can't just set UpdRootD to /mnt/sdcard since we can't use it when we have the sdcard mounted as USB mass storage, so we need to hook up that with the volume manager. Also, what happens if the user wants to use UMS while we download an update? Dave, can we prevent UMS mounting while we are busy using the sdcard?
Assignee: nobody → fabrice
So, I see a couple of scenarios: Case 1: UMS is off (either due to being USB unplugged, or option disabled). Update starts to sdcard. UMS becomes enabled (user plugs in cable and option is set). For this case, we could add something (conceptually similar to a wakelock) which causes the AutoMounter to defer until the count reaches zero. Case 2: UMS is on and phone is actively shared with PC. Update wants to start. For this case, once the phone is shared with the PC, we can't turn off sharing until the user unplugs the USB cable, so we would need to defer the download until sharing is turned off. To do this properly, we should probably reflect why the UMS mount is being deferred in the settings app (there is currently a place to do this and there is a string which is used to indicate that we're waiting for the user to unplug to finish turning off UMS). It would require a new string for translation.
Fabrice, Marshall indicated to me that this bug was subsumed by bug 785124, which has a WIP patch too. Can we dup this bug to 785124? Fabrice, if you cycles to steal that one from me, that'd be great :).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.