Clutterreport: /storage/emulated/0/SMSBackupRestore

[Solomon1732]

Target

Target: /storage/emulated/0/SMSBackupRestore
Prefix-free: SMSBackupRestore
Path-prefix: /storage/emulated/0/
Type: DIRECTORY
Location: SDCARD
Current keeper state: true
Suggested keeper state: false

Suggested owners

Current owners

None

SD Maid

Version: 4.6.3 (40603)

Device

Fingerprint: lge/p1bssn_global_com_nr/p1bssn:6.0/MRA58K/1619212434f26:user/release-keys

Comment

It's a leftover from SMS Backup & Restore

[d4rken]

@Solomon1732 There are multiple apps with the exact same name, can you give me a link or packagename?

[Solomon1732]

This is the package name:
com.riteshahu.SMSBackupRestore

This is the app in question:
https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore&hl=en

The steps to produce it are:

1. Install app
2. Use app to backup information
3. In /storage/emulated/0 see resulting directory

The directory is not created when the app is installed. Only when the app is used to backup SMS.

It's used to hold the resulting backup file, so my guess is that it's left there even after the app is removed so that users can still have the backups.

I've notices that SD Maid has a problem identifying the source of the directory only after SMS Backup is uninstalled. When the app in question is still installed SD Maid has no problem identifying the owner app.

[d4rken]

We should probably check the other apps with the same name too, shouldn't we?
https://www.google.de/search?q=google+play+SMS+Backup+%26+Restore

There seems to be quite a lot of apps with that exact name, they could also use the same backup directory.

The directory is not created when the app is installed.

Apps can not do anything after being installed unless the app is manually opened once or the device reboots.

I've notices that SD Maid has a problem identifying the source of the directory only after SMS Backup is uninstalled. When the app in question is still installed SD Maid has no problem identifying the owner app.

I've checked and the app is already in the database. Can you check whether it's just not shown as corpse because you do not have "Show desirable corpses" enabled in the settings?

[Solomon1732]

We should probably check the other apps with the same name too, shouldn't we?
https://www.google.de/search?q=google+play+SMS+Backup+%26+Restore

Yikes... I can see why the request for the package name...

I've checked and the app is already in the database. Can you check whether it's just not shown as corpse because you do not have "Show desirable corpses" enabled in the settings?

It's indeed the reason. It wasn't checked. Thanks.
Sorry for opening an unneeded issue.

Is there a web page listing the apps already in the databases? Or some way? It could aid in avoiding such false positives in the future. Adding something like that to the app itself would be a major headache, I think.

[d4rken]

No worries, we could still use this ticket to check the other apps named like this if you have time. Theoretically I could upload the database files, but it's no longer straight up searching. SD Maid also uses "dynamic markers" which are code modules that generate database entries based on existing file patterns. Next update will also introduce regex based package matching in addition to the already existing regex based path matching. So to reliably search this online we would need some logic too... In some cases SD Maid then doesn't know who owns an item until an app owning that item is installed (corpse until pattern X is detected, if so, pattern match is owner). Seeing the amount of reports here, I'm not sure how many people would use it to look these things up. A lookup page in SD Maid would actually be easier. Theoretically that's what the explorer is supposed to do and does, just no info screen yet. I just noticed though that in this report, SD Maid should have listed the app under current owner... Will look into that...