Cleanup after Link2SD/Apps2SD #674
Comments
|
Can you show me the directories contents you want SD Maid scan? Doesn't Link2SD clean up after the apps it linked? |
|
Normally, yes, Link2SD does clean up after itself when an app gets uninstalled, but certain circumstances will prevent that activation. Resetting the device, for example. And Link2SD has its own built-in cleaner that can be activated within the app. However, the built-in cleaner needs a lot of work, as it currently wants to clear the entire /data/sdext2 folder of all files - including any user-created ones while leaving the folders - including the data for the apps that are no longer installed. Anyway, this request is just so it can be easily cleaned all in one place w/ the rest of the system. As for what to clean, it's just scanning for apps/data that are no longer installed but with an extra base search path for each section, which I listed above. The only thing I didn't mention before because I didn't think of it would be that an exception would have to be made for the /data/app > /data/sdext2 base folder pair (the first one I listed above) to recognize folders that aren't apps. Since Link2SD uses the package name as the folder name, any folders that don't start with "com.", "org.", "net.", "de.", or any other common package naming scheme can be ignored. The other folder pairs don't need this check since they have their own subfolders. As an example, here's a small screenshot of part if my /data/sdext2 folder: The directory structure inside each base path is the same, so for example, /data/dalvik-cache has each architecture in separate subfolders, so the ARM architecture would have its stuff stored under /data/dalvik-cache/arm/package.name.dex, and if it gets moved with Link2SD, it's at /data/sdext2/dalvik-cache/arm/package.name.dex. |
|
Can you use the "Save directory structure" action from SD Maids explorer on
the /data/sdext2 folder?
It will produce a logfile which we can use to get a better understanding of
the structures.
I'm currently asking myself if we need an extra CorpseFinder filter
(because we need custom matching), or if we could add the pathes as extra
locations.
Meaning "/data/sdext2/data" as PRIVATE_DATA location in addition to the
normal "/data/data", if the naming schemes inside the Link2SD folders are
exactly the same then we could process them with the same modules we
already have for the default directories.
This would fail for the apk files though, because of:
As far as I understood it , Link2SD uses `/data/sdext2/app.package.dir`
instead of `/data/sdext2/app/app.package.dir`... why doesn't it use the
same subdirectory system like it uses for `data` and `dalvik-cache`???
Pointing the current `/data/app` module at `/data/sdext2` would lead to
false positives... Modifying it, i.e. exclusions, would then worsen the
results for `/data/app`...
2017-01-05 15:17 GMT+01:00 Yowlen <[email protected]>:
… Normally, yes, Link2SD does clean up after itself when an app gets
uninstalled, but certain circumstances will prevent that activation.
Resetting the device, for example. And Link2SD has its own built-in cleaner
that can be activated within the app. However, the built-in cleaner needs a
lot of work, as it currently wants to clear the entire /data/sdext2 folder
of all files - including any user-created ones while leaving the folders -
including the data for the apps that are no longer installed.
Anyway, this request is just so it can be easily cleaned all in one place
w/ the rest of the system.
As for what to clean, it's just scanning for apps/data that are no longer
installed but with an extra base search path for each section, which I
listed above. The only thing I didn't mention before because I didn't think
of it would be that an exception would have to be made for the /data/sdext2
apk folder search (the first one I listed above) to recognize folders that
aren't apps. Since Link2SD uses the package name as the folder name, any
folders that don't start with "com.", "org.", "de.", or any other common
package naming scheme can be ignored.
As an example, here's a small screenshot of part if my /data/sdext2 folder:
[image: tmp_12209-screenshot_2017-01-05-09-11-561924716089]
<https://cloud.githubusercontent.com/assets/17078692/21683497/9a79568a-d327-11e6-86c6-3701efe50e91.png>
The first folder follows the common naming scheme, so it would be checked
against the installed package lists just as if it were in /data/app. The
others don't, so they'd be ignored.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#674 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABX1_TtxYemSmNSgKBF5AGdCEo7fPWO2ks5rPPuSgaJpZM4LbFT_>
.
|
|
I hate hitting the wrong buttons. lol Anyway, there ya go. |
|
Most people wouldn't even have a secondary partition in the first place, let alone use it for anything other than App2SD stuff. I think just ignoring Link2SD's subfolders & any without a period, along with any non-apk files in the root folder (for 4.x compatibility) would be sufficient. Also, if you need it, I can give a directory structure from my Kit Kat tablet to help ensure that compatibility. |
|
I think just ignoring Link2SD's subfolders & any without a period, along with any non-apk files in the root folder (for 4.x
This is the issue if would want to just add these link2sd locations to SD
Maids normal pool of locations. Which would be quite clean because then all
tools automatically process them. If we modify the default corpse module
used for `/data/app` in that way, we make it less effective because all
items that don't fit the pattern are corpses in `/data/app`...
Thinking about it though... the folders are already being processed by
other tools due to being symlinked to known locations (i.e. `/data/data`) adding them again
would lead to duplicate work.
I'll have to think about this some more...
Also, if you need it, I can give a directory structure from my Kit Kat tablet to help ensure that compatibility.
The more the better, preferably we want data from 4.1, 4.4, 5.X, 6.X and
7.X to make sure there are no unexpected differences in the structure
Link2SD creates. Maybe the Link2SD dev has documentation somewhere?
2017-01-05 15:52 GMT+01:00 Yowlen <[email protected]>:
… Most people wouldn't even have a secondary partition in the first place,
let alone use it for anything other than App2SD stuff. I think just
ignoring Link2SD's subfolders & any without a period, along with any
non-apk files in the root folder (for 4.x compatibility) would be
sufficient.
Also, if you need it, I can give a directory structure from my Kit Kat
tablet to help ensure that compatibility.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#674 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABX1_YOUihsoHd2U_cupvMEW1DSYe-axks5rPQPIgaJpZM4LbFT_>
.
|
|
Well, the earlier one was from my 5.1.1 device w/ the custom ROM reboot
issue (works w/ the latest beta btw, thanks). Here's the one from my 4.4.2
tablet. I forgot that app-lib was used as a shared library folder pre-5.x
instead of separate libraries per app stored in /data/app, so seeing that
subfolder surprised me at first since I don't use my tablet much anymore.
lol
Unfortunately, I don't have 6.x/7.x so I can't provide anything regarding
them. Nougat is completely out of the question for me, but I may have some
luck in the next few months for Marshmallow. My phone's official ROM was
supposed to be updated to Marshmallow last month, but I think the version
number scheme change LG did screwed things up for the OTA delivery, so no
one w/ an H345 or MS345 has received it yet even though it's listed on
T-Mobile's page (sans download link, sadly). If they fix it, and I can get
it installed, or preferably a custom ROM beats them to it (the dev on XDA
who made the CM12.1 port is working on porting CM13 atm), I can see about
providing a directory structure dump for it.
4.4.2
|
|
Got Link2SD 4.0.13 setup on a [email protected]. On your log from earlier: Where does the dir Edit: |
|
Politics & Linux are user-created folders, yes. I use the Linux folder to store chroot images for Linux Deploy. All folders from my 5.x log that relate to Link2SD are listed in my first post. All the rest are of my own creation (usually using a root explorer app) for various purposes. |
I don't have |
|
On a side note, does |
d4rken
changed the title
|
For
|
|
Seems almost the same.
With both being so similar, we could probably make the filter cover both? I don't see the difference you mean. I installed both apps and they both create scripts and symlink app files. Testing on my Moto [email protected], file structure seems the same as your 5.0.1 ROM. We got the How is multi-user environment handled? Seems both apps symlinking style would break on multi-user environments because |
|
Huh. I didn't know that app existed, tbh.
As for multi-user, I don't know, as I've never used that part of Android.
Edit: Thanks for showing me that app. After playing around with it, it looks a whole lot cleaner and more powerful than Link2SD - both in UI & storage methods. Plus, the Folder Mount section means I can get rid of my folder mount app that I use for the various internal Music/Pictures/etc. folders.
Also, to clarify: Your simulated storage folders ( `/sdcard/Android/data` & `/sdcard/Android/obb` ) gave the proper link for Link2SD, but Apps2SD stores them in `/data/sdext2/Android`, not `/data/sdext2/data`, which is where the internal data storage ( `/data/data` ) gets linked to for both apps.
|
Public dataLink2SDApps2SD:Obb dataLink2SDApps2SDDalvik-Cache
Link2SDApps2SDPrivate dataBothAPK dataLink2SDApps2SDApp library dataLink2SDApps2SD |
|
Public Data & Obb: Dalvik Cache: The profiles folder isn't linked. It's just a bunch of 0-byte markers from what I see. And there's a slight difference between how App Library: While Link2SD moves the libraries with the data on 5.x+, Apps2SD does separate the two, using the same link destination as Link2SD does for 4.x-. i.e. I'm starting up my 4.4.2 tablet to test Apps2SD now. I'll edit this when I have the results. Edit: I can confirm Apps2SD uses the same layout on 4.4.2 as it does on 5.1.1. |
|
I've updated my post, please check again. Did we miss anything? Should differentiate between APIs when checking? Probably not, as otherwise we can't detect corpses from older Android versions. This is a root only thing anyways so the user could have upgraded his ROM. I think we can easily parse the packagename in every case, not sure if for apks we should parse the packagename or try to get it from the apk. Probably the apk because it's safer? So this seems to viable, "just" needs a lot of regex love and unit tests would probably be good too. |
|
Seems accurate except for one thing I forgot about until I double-checked my 4.4.2 directory structure dump: Link2SD's Dalvik Cache on 4.x is like Apps2SD's layout - it doesn't separate by architecture. Oh, and one other thing: Link2SD doesn't allow linking system apps, so no |
|
Your reference is exceptionally useful: #674 (comment) You may also want to add XInternalSD: http:https://repo.xposed.info/module/com.pyler.xinternalsd |
|
@Gitoffthelawn I'm not sure it's the same functionality. |
|
Hmmm... I'm not sure either because I am not too familiar with Link2SD and Apps2SD. The idea behind XInternalSD is to map internal storage to the external microSD card. |
|
Yeah, it's definitely not the same. Link2SD/Apps2SD uses Besides, Link2SD & Apps2SD use a second, normally-invisible/nonexistent partition on the SD card, which is what we're attempting to clean here. XInternalSD only changes file storage to where it would normally be on the primary partition, so SD Maid would already clean any junk there. |
|
@Yowlen Thank you for the details. Much appreciated! 👍 |
|
Thank you fellas ☺ |
|
Looking for testers for this. If anyone has time please send a quick mail to support. |
|
@Gitoffthelawn @Yowlen Had a chance to test the filter in v4.6.0? |
|
I observed it was in action as it detected the empty Apps2SD folder on the external SD's primary partition, but forgot to test more thoroughly until I got this reminder. I created a few false folders in each area, and it seemed to work almost perfect. The only issue is for Link2SD's apk layout. Unless the folder has |
Doesn't every Link2SD apk have a Can you show me some samples where it's named differently? |
|
Honestly, I'm not entirely sure. I think I recall seeing some in the past, but I may have confused it with |
|
I think that may be the case, but should I be wrong and you spot such behavior, please make new bug ticket, ok? |
Link2SD is an app that automates the various App2SD scripts found on various Android root forums. It'd be nice to have a detection system for app remnants on the primary & secondary SD card partitions. It mounts the secondary SD card partition at /data/sdext2, and stores things as follows:
/data/app/app.package.dir > /data/sdext2/app.package.dir
/data/data/app.package.dir > /data/sdext2/data/app.package.dir
/data/dalvik-cache > /data/sdext2/dalvik-cache
/storage/emulated/0/Android/data > /data/sdext2/Link2SD/bind/data OR /storage/sdcard1/Link2SD/bind/data
/storage/emulated/0/Android/obb > /data/sdext2/Link2SD/bind/obb OR /storage/sdcard1/Link2SD/bind/obb
Edit: Forgot about the Dalvik cache. XD
The text was updated successfully, but these errors were encountered: