LightBlog

jeudi 13 avril 2017

I/O Bug on OxygenOS 4 is Causing Deleted Files to Still Take up Space

You’ve just finished flashing a ROM update from our forums and want to clean up the installation files to save storage space. You open up MiXplorer by XDA Recognized Developer HootanParsa and navigate to where you saved the ROM files. You then delete the files to reclaim some storage space – or so you thought.

Apparently, there’s an I/O bug on OxygenOS that affects the OnePlus 3 and OnePlus 3T that is causing some storage misbehavior oddities such as the inability to regain storage space after deleting some files. When users attempt to delete a file using any file manager app apart from the stock Android file picker or the OnePlus file manager, the storage allocated to that file does not get freed up as it should be. The only way to reclaim this storage space is to reboot the phone.


Storage Bug on OxygenOS 4.X.X

Users of the blu_spark kernel by XDA Recognized Contributor eng.stk first encountered this bug a few weeks ago. What they discovered was that certain files, usually zip files, fail to have their claimed storage space de-allocated once the user sets to delete them using third-party file explorers (such as the aforementioned MiXplorer, Root Explorer, Solid Explorer, FX File Explorer, etc.) or multimedia applications. Furthermore, if a user tries to delete a file and it misbehaves, the users discovered that subsequent file deletions would also start becoming buggy, until they rebooted.

What you would normally expect to happen after deleting files: your storage space being reclaimed

XDA Senior Member Reli4nth was able to replicate this bug even on non-OxygenOS ROMs (such as Resurrection Remix) consistently by performing the following steps with Solid Explorer:

  1. Copy a ROM zip file (530MB) from OTG to internal storage. Available storage space decreases.
  2. Duplicate the ROM zip. Available storage space decreases.
  3. Delete the duplicated ROM zip. Available storage space remains the same.
  4. Delete the original ROM zip. Available storage space remains the same.

What we would normally expect is that the available storage space would decrease by ~1GB after copying and then duplicating the ROM zip, but then that storage space would be reclaimed by deleting both the duplicated and the original ROM zip. But that wasn’t the case, even on this non-OxygenOS ROM. So what’s going on? It isn’t exactly clear what is causing this bug, but eng.stk believes that this bug is related to OnePlus’s implementation of SDCardFS, and that any custom ROM that includes certain storage binaries from OxygenOS is also affected by this bug.


SDCardFS and the Storage Bug

Eventually, users discovered that this bug was not affecting ROMs that had disabled SDCardFS. eng.stk believes that this bug is related to SDCardFS behavior in Android Nougat and userspace permissions, and states that a simple kernel update alone won’t fix this issue. Instead, the solution is simply to disable SDCardFS entirely, at least for the time being. You can force any ROM that has SDCardFS enabled by default to disable it and drop back to FUSE by commenting out a specific line in /system/build.prop.

Change

ro.sys.sdcardfs=true

to

#ro.sys.sdcardfs=true

If you would like to implement this fix without modifying the /system partition, then you can also enable a Magisk module created by eng.stk. Just download the zip, import it into Magisk Manager, enable the module, then reboot your device.

For a detailed explanation of what SDCardFS is, I highly recommend you read through my previous article on this subject. The gist of it is that SDCardFS is an in-kernel solution for managing the virtual filesystems on Android. It allows for /data/media (your device’s “external” storage, AKA /sdcard AKA /storage/emulated) to be emulated as a FAT32 filesystem even though /data is mounted as EXT4. This is necessary because Google wanted to give Android apps the permission to access only their own data folders by default in the external storage, so that app data can be isolated from other apps unless another app has been explicitly granted the permission to read the external storage by the user.

Samsung originally developed SDCardFS as a replacement for FUSE (Filesystem in Userspace) which accomplished this same task, however, FUSE had several problems such as increased I/O overhead, double caching, and odd file management behaviors which you can read about in more detail in my previous article. As a result of FUSE’s drawbacks, several OEMs such as Huawei and OnePlus have started using SDCardFS in place of FUSE in their devices. Even Google is moving to SDCardFS for Android O as well, for example.


Awaiting an Official Fix

We were first notified of this bug by eng.stk on April 2nd, 2017. We notified our contacts at OnePlus shortly thereafter, but because our contacts were on holiday until April 7th, we did not hear back. We have followed up on this matter, but we still have not heard a response from OnePlus’s engineering team. In the public interest, however, we decided that we would go ahead and notify the community regarding this I/O bug anyways.

Admittedly, this bug isn’t a huge deal as it in no way cripples functionality. It’s at most a minor inconvenience because all a user who is afflicted by this bug has to do is reboot the device to reclaim their storage space, or stick to using the stock file explorer applications.

However, a bug is a bug, and it’s not something we felt we should ignore given how many users are speaking up about it. We hope that by drawing attention to this issue, that OnePlus is able to fix this storage bug in a subsequent release of OxygenOS. We should note that we haven’t heard any examples of this bug afflicting Samsung or Huawei devices yet, but if it does affect your device, please do let us know!



from xda-developers http://ift.tt/2nJ9TXD
via IFTTT

Aucun commentaire:

Enregistrer un commentaire