Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #154978 > unrolled thread

Android 6 internal vs SD storage

Back to article view | Back to comp.mobile.android

Contents

  Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-14 15:23 -0700
    Re: Android 6 internal vs SD storage VanguardLH <V@nguard.LH> - 2026-08-14 20:33 -0500
      Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-14 17:47 -0800
      Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-14 22:37 -0400
        Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-14 22:46 -0400
          Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-14 20:12 -0800
        Re: Android 6 internal vs SD storage Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-15 09:34 +0100
          Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-15 10:23 -0400
            Re: Android 6 internal vs SD storage "Carlos E. R." <robin_listas@es.invalid> - 2026-08-15 19:25 +0200
              Re: Android 6 internal vs SD storage Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-16 01:14 +0100
                Re: Android 6 internal vs SD storage "Carlos E. R." <robin_listas@es.invalid> - 2026-08-16 11:06 +0200
                Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-16 11:52 -0400
                  Re: Android 6 internal vs SD storage Paul <nospam@needed.invalid> - 2026-08-16 13:13 -0400
                    Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-16 21:26 -0400
                      Re: Android 6 internal vs SD storage Paul <nospam@needed.invalid> - 2026-08-16 23:19 -0400
        Re: Android 6 internal vs SD storage Steve Hayes <hayesstw@telkomsa.net> - 2026-08-17 08:32 +0200
    Re: Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-14 19:55 -0700
      Re: Android 6 internal vs SD storage Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-15 09:25 +0100
        Re: Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-15 09:54 -0700
          Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-15 09:22 -0800
            Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-15 10:12 -0800
      Re: Android 6 internal vs SD storage Jim Jackson <jj@franjam.org.uk> - 2026-08-15 10:59 +0000
    Re: Android 6 internal vs SD storage "s|b" <me@privacy.invalid> - 2026-08-15 19:48 +0200
      Re: Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-15 11:48 -0700

Page 1 of 2  [1] 2  Next page →

#154978 — Android 6 internal vs SD storage

I do not use cell phones conventionally; I don't carry a phone, I don't 
normally even turn a phone on. I just now subscribed to this group to 
ask a question, but I haven't read any recent msg threads here.

I have an old cellphone w/ Android 6 and no cell plan which I use for 
various purposes via wifi, camera, & music. I have a newer tablet phone 
which does have a plan which I use occasionally via wifi.

I am fairly ignorant of navigating my old cellphone's features, which is 
why I'm here now.

Whenever I start the phone, I'm informed about how low the 8G internal 
storage is. I only recently changed the settings to use the 32G SD card 
by default instead of internal.

My problem is that I can't find a way to 'get rid of' any data in 
internal storage that is causing my low storage condition.

The online advice I've found hasn't been helpful to me.


-- 
Mike Easter

[toc] | [next] | [standalone]

#154980

Mike Easter <MikeE@ster.invalid> wrote:

> I do not use cell phones conventionally; I don't carry a phone, I don't 
> normally even turn a phone on. I just now subscribed to this group to 
> ask a question, but I haven't read any recent msg threads here.
> 
> I have an old cellphone w/ Android 6 and no cell plan which I use for 
> various purposes via wifi, camera, & music. I have a newer tablet phone 
> which does have a plan which I use occasionally via wifi.
> 
> I am fairly ignorant of navigating my old cellphone's features, which is 
> why I'm here now.
> 
> Whenever I start the phone, I'm informed about how low the 8G internal 
> storage is. I only recently changed the settings to use the 32G SD card 
> by default instead of internal.
> 
> My problem is that I can't find a way to 'get rid of' any data in 
> internal storage that is causing my low storage condition.
> 
> The online advice I've found hasn't been helpful to me.

My guess is you are asking about the Adoptive Storage feature.  Once you
adopt the SD card to augment your phone's internal storage, everything
on the SD card is erased, and it gets encrypted to lock that SD card to
that phone.  If you ever want to use the SD card elsewhere, you will
have to un-adopt the SD card which formats it.  Adoption is destructive
when you want to enable it, and when you want to release it.

https://source.android.com/docs/core/storage/adoptable
https://www.androidcentral.com/adoptable-storage

Adoption still has app first using internal storage, especially if you
have not enabled Adoptable Storage in the app settings, and then uses
adopted memory.  To clear out your internal storage means uninstalling
apps, moving data files elsewhere, or checking if Adoptable Storage is a
feature you can use *and* some apps will also use.  Move the data files
to removable storage (i.e., user data, not app data), if possible.  Then
go check each app to see if it was coded to support Adoptable Storage.

Some apps have an option to use adopted memory, but you have to enable
it.  Under settings -> Apps -> choose an app, and check if there is an
option to enable Adoptable Storage in that app.  However, even before
that, some apps let you chose where to store data files, like offline
maps, but then you won't have a choice if you used the SD card as
Adoptable Storage.  Not all apps can be [partially] relocated to adopted
memory.  Often the core program remains in internal storage, and its
ancilliary files and data files can move to adopted memory.  Not all
apps have the option to use adopted memory.  Some of the core app must
be in internal storage, but how much can be split out to Adoptable
Storage are decisions made by the app author.  The app author decides
whether or not adoptive memory is supporte, how it gets used, how to
split up the core app, or may decide not use adopted memory at all since
it requires more code and support by them.

After adopting the SD card to augment internal storage, you'll have to
visit each app to see if it supports Adoptable Storage.  If not, the app
stays in internal storage; however, sometimes you can choose to save
data files elsewhere (but elsewhere won't exist if you converted the SD
card to Adoptable Storage).  If no apps support Adoptable Storage, you
can't move anything from internal storage (but may have a choice to
store data files elswhere), and you have the same "out of space" issue
as before.

If any part of the core app, or its ancilliary files, can be moved to
adopted memory, make sure you get a really really fast SD card, and be
sure to check the write specs, too.  And realize all those writes are
destructive to flash drives, so the SD card will get slower over time
with lots of use.  The core app files probably only change with new
versions of the apps, but without the SD card to elect to move the app's
data files to there they could be in Adoptable Storage which stresses
more that flash drive.

I tested Adoptable Storage a long time ago, but gave up on it.  Split
apps got slower, in general.  Instead there were enough apps where I
could tell them to store their data files on the SD card, like map apps
that can store their offline maps on the SD card.  I also reviewed the
installed apps to see which I installed for curiosity, or one-time or
rare-time use, and uninstalled them.  Stop, clear cache, clear data,
then uninstall.  Per some other users, the APK is left behind after
uninstall, so blindly installing apps to test them leaves crap behind
occuping internal storage after uninstalling them.  That's why I don't
install apps just to see what they do, and if they fit my needs, because
I end up with some remnant lost storage after an uninstall.  I'm sure
there are ways to clean up the orphaned APK repositories, but easier not
to shit on the phone in the first place rather than have to clean it
later.

[toc] | [prev] | [next] | [standalone]

#154982

VanguardLH wrote:
> I tested Adoptable Storage a long time ago, but gave up on it.

In concurrence with what was said above, many of us long ago, when we had
phones with less than 32GB of internal storage, tried "adoptable storage".

Most of us, including me, hated it.
Slow. Complicated. Restrictive. 

We did it only because we had to.
That seems to be the situation the OP is stuck in.

When phones started coming with 32GB internal storage, we mostly moved to
adding the sd card as "portable storage", which is like plugging a USB
stick into a PC, only we're plugging the card into the phone slot instead.

Even when phones routinely came with 64GB and now 128GB, given more than
half of the phones today (60%) have sd slots, people are still popping in
the sd card as portable storage (which cannot be gotten any other way).

Most sd cards now, for about 30 bucks in the USA, are about 128GB in size,
but of course most phones now can take double, triple, and quadruple that.

While we all lived through 8GB phones, I can't imagine using one today.
I'm sure it works, but you can't add too many apps or images or data.
-- 
Usenet allows purposefully helpful people to pool their experiences.

[toc] | [prev] | [next] | [standalone]

#154983

In comp.mobile.android, on Fri, 14 Aug 2026 20:33:21 -0500, VanguardLH
<V@nguard.LH> wrote:

>Mike Easter <MikeE@ster.invalid> wrote:
>
>> I do not use cell phones conventionally; I don't carry a phone, I don't 
>> normally even turn a phone on. I just now subscribed to this group to 
>> ask a question, but I haven't read any recent msg threads here.
>> 
>> I have an old cellphone w/ Android 6 and no cell plan which I use for 
>> various purposes via wifi, camera, & music. I have a newer tablet phone 
>> which does have a plan which I use occasionally via wifi.
>> 
>> I am fairly ignorant of navigating my old cellphone's features, which is 
>> why I'm here now.
>> 
>> Whenever I start the phone, I'm informed about how low the 8G internal 
>> storage is. I only recently changed the settings to use the 32G SD card 
>> by default instead of internal.
>> 
>> My problem is that I can't find a way to 'get rid of' any data in 
>> internal storage that is causing my low storage condition.
>> 
>> The online advice I've found hasn't been helpful to me.
>
>My guess is you are asking about the Adoptive Storage feature.  Once you
>adopt the SD card to augment your phone's internal storage, everything

Are SD cards always adopted like this, or acn they be used without
encryption and locking? 

>on the SD card is erased, and it gets encrypted to lock that SD card to
>that phone.  If you ever want to use the SD card elsewhere, you will
>have to un-adopt the SD card which formats it.  Adoption is destructive
>when you want to enable it, and when you want to release it.

When I have time, I reed every post in the android group, and the
windows and firefox groups. 

But I never have eough time anymore to do that and I just red this
thread because it was next, and by golly, it relates to a question I was
working on. 

I have other copies of the pictures but I still wanted to copy the ones
on the SD card from my BROKEN phone (in case by some miracle they
weren't the same as the ones from the same dates that I already have). I
couldn't open the few I tried to oprn and when I tried to copy all 9
gigs in win10, it did 4% and stopped with no message.   I was going to
work on it some more later.  But now I know why. 

For the record and assuming I didn't have 3 other copies, is there a way
to unencrypt the files so I can still see my photos? 

If it's time-consuming or impossible, I'll just reformat the 64GB SD
card to exFAT, right?   Is quick-format good enough? 


All of this, and especially if the files are irrecoverable, lowers the
value of an SD card, not completely but somewhat, of course, for those
in the previous thread who say it's of no value.  I had thought
otherwise, that it would be like the harddrive in a computer, easily
available after the computer failed***. 

I should also mention that, though the phone created a data subdirectory
for every app, all 220, and some of them had multiple subdirectories, it
took me a long time to check but none except for the photo/video
directory had more than 2 files, both under 100 bytes.   So only the
photos were saved there and only after I set some setting to save to the
SD card, for fear internal storage would fill up. 

Of course the external storage is no worse than the internal storage
here, because it will be hard and probably impossible to get anything
out of internal storage now that the phone is broken.  It's not like a
computer , is it, where you can open it up and take out the storage, or
is it? 

***Why *do* they encrypt the SD card and lock it to the phone? If they
didn't, it would be more useful after the phone failed. 



>https://source.android.com/docs/core/storage/adoptable
>https://www.androidcentral.com/adoptable-storage
>
>Adoption still has app first using internal storage, especially if you
>have not enabled Adoptable Storage in the app settings, and then uses
>adopted memory.  To clear out your internal storage means uninstalling
>apps, moving data files elsewhere, or checking if Adoptable Storage is a
>feature you can use *and* some apps will also use.  Move the data files
>to removable storage (i.e., user data, not app data), if possible.  Then
>go check each app to see if it was coded to support Adoptable Storage.
>
>Some apps have an option to use adopted memory, but you have to enable
>it.  Under settings -> Apps -> choose an app, and check if there is an
>option to enable Adoptable Storage in that app.  However, even before
>that, some apps let you chose where to store data files, like offline
>maps, but then you won't have a choice if you used the SD card as
>Adoptable Storage.  Not all apps can be [partially] relocated to adopted
>memory.  Often the core program remains in internal storage, and its
>ancilliary files and data files can move to adopted memory.  Not all
>apps have the option to use adopted memory.  Some of the core app must
>be in internal storage, but how much can be split out to Adoptable
>Storage are decisions made by the app author.  The app author decides
>whether or not adoptive memory is supporte, how it gets used, how to
>split up the core app, or may decide not use adopted memory at all since
>it requires more code and support by them.
>
>After adopting the SD card to augment internal storage, you'll have to
>visit each app to see if it supports Adoptable Storage.  If not, the app
>stays in internal storage; however, sometimes you can choose to save
>data files elsewhere (but elsewhere won't exist if you converted the SD
>card to Adoptable Storage).  If no apps support Adoptable Storage, you
>can't move anything from internal storage (but may have a choice to
>store data files elswhere), and you have the same "out of space" issue
>as before.
>
>If any part of the core app, or its ancilliary files, can be moved to
>adopted memory, make sure you get a really really fast SD card, and be
>sure to check the write specs, too.  And realize all those writes are
>destructive to flash drives, so the SD card will get slower over time
>with lots of use.  The core app files probably only change with new
>versions of the apps, but without the SD card to elect to move the app's
>data files to there they could be in Adoptable Storage which stresses
>more that flash drive.
>
>I tested Adoptable Storage a long time ago, but gave up on it.  Split
>apps got slower, in general.  Instead there were enough apps where I
>could tell them to store their data files on the SD card, like map apps
>that can store their offline maps on the SD card.  I also reviewed the
>installed apps to see which I installed for curiosity, or one-time or
>rare-time use, and uninstalled them.  Stop, clear cache, clear data,
>then uninstall.  Per some other users, the APK is left behind after
>uninstall, so blindly installing apps to test them leaves crap behind
>occuping internal storage after uninstalling them.  That's why I don't
>install apps just to see what they do, and if they fit my needs, because
>I end up with some remnant lost storage after an uninstall.  I'm sure
>there are ways to clean up the orphaned APK repositories, but easier not
>to shit on the phone in the first place rather than have to clean it
>later.

[toc] | [prev] | [next] | [standalone]

#154985

In comp.mobile.android, on Fri, 14 Aug 2026 22:37:01 -0400, micky
<NONONOmisc07@fmguy.com> wrote:

>
>>My guess is you are asking about the Adoptive Storage feature.  Once you
>>adopt the SD card to augment your phone's internal storage, everything
>
>Are SD cards always adopted like this, or acn they be used without
>encryption and locking? 

Maria's post and a little googling answered this.  I'm assuming mine was
adopted since I can't read or copy** it in the computer, but I don't
remember doing anything to adopt it, and this was a new Xiaomi phone. 

**Hmmm.  Shouldn't I be able to at least copy encrypted files? 

[toc] | [prev] | [next] | [standalone]

#154988

micky wrote:
>>>My guess is you are asking about the Adoptive Storage feature.  Once you
>>>adopt the SD card to augment your phone's internal storage, everything
>>
>>Are SD cards always adopted like this, or acn they be used without
>>encryption and locking? 
> 
> Maria's post and a little googling answered this.  I'm assuming mine was
> adopted since I can't read or copy** it in the computer, but I don't
> remember doing anything to adopt it, and this was a new Xiaomi phone. 
> 
> **Hmmm.  Shouldn't I be able to at least copy encrypted files?

It's been a long time since I used "adoptable storage", which becomes an
extension of the internal storage, but as long as you leave it in the
phone, and the phone is unlocked with your pin (if needed), then you can
see everything on the sd card and copy it and do what you want with it.

The data on the sd card used as adoptable storage is only locked up when
the card is out of the phone (or if the phone is off, of course), AFAIK.

[toc] | [prev] | [next] | [standalone]

#154992

On 2026-08-15, micky wrote:

> In comp.mobile.android, on Fri, 14 Aug 2026 20:33:21 -0500, VanguardLH
> <V@nguard.LH> wrote:
>
>>Mike Easter <MikeE@ster.invalid> wrote:
>>
>>> I do not use cell phones conventionally; I don't carry a phone, I don't 
>>> normally even turn a phone on. I just now subscribed to this group to 
>>> ask a question, but I haven't read any recent msg threads here.
>>> 
>>> I have an old cellphone w/ Android 6 and no cell plan which I use for 
>>> various purposes via wifi, camera, & music. I have a newer tablet phone 
>>> which does have a plan which I use occasionally via wifi.
>>> 
>>> I am fairly ignorant of navigating my old cellphone's features, which is 
>>> why I'm here now.
>>> 
>>> Whenever I start the phone, I'm informed about how low the 8G internal 
>>> storage is. I only recently changed the settings to use the 32G SD card 
>>> by default instead of internal.
>>> 
>>> My problem is that I can't find a way to 'get rid of' any data in 
>>> internal storage that is causing my low storage condition.
>>> 
>>> The online advice I've found hasn't been helpful to me.
>>
>>My guess is you are asking about the Adoptive Storage feature.  Once you
>>adopt the SD card to augment your phone's internal storage, everything
>
> Are SD cards always adopted like this, or acn they be used without
> encryption and locking?

Storage cards can definitely be used without encryption, and, at least
on Android 4.2, can also be used to store installed apps without
filesystem-wide encryption (if there is some encryption, it's localized
to the relevant files).

>>on the SD card is erased, and it gets encrypted to lock that SD card to
>>that phone.  If you ever want to use the SD card elsewhere, you will
>>have to un-adopt the SD card which formats it.  Adoption is destructive
>>when you want to enable it, and when you want to release it.
>
> When I have time, I reed every post in the android group, and the
> windows and firefox groups. 
>
> But I never have eough time anymore to do that and I just red this
> thread because it was next, and by golly, it relates to a question I was
> working on. 
>
> I have other copies of the pictures but I still wanted to copy the ones
> on the SD card from my BROKEN phone (in case by some miracle they
> weren't the same as the ones from the same dates that I already have). I
> couldn't open the few I tried to oprn and when I tried to copy all 9
> gigs in win10, it did 4% and stopped with no message.   I was going to
> work on it some more later.  But now I know why.

Are you certain that the card itself is OK hardware-wise and has no
errors in the filesystem? If not, you may be better off copying with
something like ddrescue. (No idea what's available for Windows NT.)

> For the record and assuming I didn't have 3 other copies, is there a way
> to unencrypt the files so I can still see my photos?
>
> If it's time-consuming or impossible, I'll just reformat the 64GB SD
> card to exFAT, right?   Is quick-format good enough?

My two cents would be: don't do that unless you're entirely sure it
can't be recoveded.

> All of this, and especially if the files are irrecoverable, lowers the
> value of an SD card, not completely but somewhat, of course, for those
> in the previous thread who say it's of no value.  I had thought
> otherwise, that it would be like the harddrive in a computer, easily
> available after the computer failed***.

Hard drives can be encrypted too. Although I think that's mainly used
with user-supplied passphrases, I'd not be surprised if the DRM in TPM
and "Secure computing" allowed for a similar thing.

> I should also mention that, though the phone created a data subdirectory
> for every app, all 220, and some of them had multiple subdirectories, it
> took me a long time to check but none except for the photo/video
> directory had more than 2 files, both under 100 bytes.   So only the
> photos were saved there and only after I set some setting to save to the
> SD card, for fear internal storage would fill up. 
>
> Of course the external storage is no worse than the internal storage
> here, because it will be hard and probably impossible to get anything
> out of internal storage now that the phone is broken.  It's not like a
> computer , is it, where you can open it up and take out the storage, or
> is it?
>
> ***Why *do* they encrypt the SD card and lock it to the phone? If they
> didn't, it would be more useful after the phone failed.

So that data cannot be extracted without permission? And perhaps to
enforce non-rooted Android limitations too... (so this one would
definitely be DRM too).

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#155007

In comp.mobile.android, on Sat, 15 Aug 2026 09:34:36 +0100, Nuno Silva
<nunojsilva@invalid.invalid> wrote:

>On 2026-08-15, micky wrote:
>
>> In comp.mobile.android, on Fri, 14 Aug 2026 20:33:21 -0500, VanguardLH
>> <V@nguard.LH> wrote:
>>
>>>Mike Easter <MikeE@ster.invalid> wrote:
>>>
>>>> I do not use cell phones conventionally; I don't carry a phone, I don't 
>>>> normally even turn a phone on. I just now subscribed to this group to 
>>>> ask a question, but I haven't read any recent msg threads here.
>>>> 
>>>> I have an old cellphone w/ Android 6 and no cell plan which I use for 
>>>> various purposes via wifi, camera, & music. I have a newer tablet phone 
>>>> which does have a plan which I use occasionally via wifi.
>>>> 
>>>> I am fairly ignorant of navigating my old cellphone's features, which is 
>>>> why I'm here now.
>>>> 
>>>> Whenever I start the phone, I'm informed about how low the 8G internal 
>>>> storage is. I only recently changed the settings to use the 32G SD card 
>>>> by default instead of internal.
>>>> 
>>>> My problem is that I can't find a way to 'get rid of' any data in 
>>>> internal storage that is causing my low storage condition.
>>>> 
>>>> The online advice I've found hasn't been helpful to me.
>>>
>>>My guess is you are asking about the Adoptive Storage feature.  Once you
>>>adopt the SD card to augment your phone's internal storage, everything
>>
>> Are SD cards always adopted like this, or acn they be used without
>> encryption and locking?
>
>Storage cards can definitely be used without encryption, and, at least
>on Android 4.2, can also be used to store installed apps without
>filesystem-wide encryption (if there is some encryption, it's localized
>to the relevant files).
>
>>>on the SD card is erased, and it gets encrypted to lock that SD card to
>>>that phone.  If you ever want to use the SD card elsewhere, you will
>>>have to un-adopt the SD card which formats it.  Adoption is destructive
>>>when you want to enable it, and when you want to release it.

Yeah, I jumped to conclusions even to ask the question. 

I posted prematurely, because Vanguard's post seemed like an magically
well-timed answer to my problem. 

This morning, I looked at the 30 jpegs and one video that I had copied,
the 4%, and all that I tried opened fine.  So I guess the card was never
adopted or encrypted at all.  (Good, since I didn't think I did that.)
The video seemed out of order no matter what sort order I imagined, but
it had been copied too and it played. 

Then I started where it left off to copy the rest.  It got through 38%
of the files and then just stopped again, no messsage.  Had to use Task
Manager and another box to close the file manager. 

Properties has all along said the SD card has no errors, but when I try
to repair it anyhow, it says it can't. 

Now, I can display the top level directory items, but when using an
after-market file manager, PowerDEsk, I try to open any of the
directories one level down, the file manager repositions at "PC" or some
high place unrelated to the SD card.  When I use the MS file manager,
this doesn't happen unless I try to open DCIM, which is where the photos
are, but it happens that way when I try to open DCIM. (Inside that is
Camera, and that has the photos.  It used to open but now doesn't even
though I never tried to write to it.  I only read, and it copied 38+4%
of the files.)

I will look into ddrescue that you mention, but I'm not optimistic. 

It sounds like a) either I should do a complete formatting, not a quick
one, or b) I should throw the card away and start over. 

(I read the rest of your post too.  Thanks for the good info.) 


>> When I have time, I reed every post in the android group, and the
>> windows and firefox groups. 
>>
>> But I never have eough time anymore to do that and I just red this
>> thread because it was next, and by golly, it relates to a question I was
>> working on. 
>>
>> I have other copies of the pictures but I still wanted to copy the ones
>> on the SD card from my BROKEN phone (in case by some miracle they
>> weren't the same as the ones from the same dates that I already have). I
>> couldn't open the few I tried to oprn and when I tried to copy all 9
>> gigs in win10, it did 4% and stopped with no message.   I was going to
>> work on it some more later.  But now I know why.
>
>Are you certain that the card itself is OK hardware-wise and has no
>errors in the filesystem? If not, you may be better off copying with
>something like ddrescue. (No idea what's available for Windows NT.)
>
>> For the record and assuming I didn't have 3 other copies, is there a way
>> to unencrypt the files so I can still see my photos?
>>
>> If it's time-consuming or impossible, I'll just reformat the 64GB SD
>> card to exFAT, right?   Is quick-format good enough?
>
>My two cents would be: don't do that unless you're entirely sure it
>can't be recoveded.
>
>> All of this, and especially if the files are irrecoverable, lowers the
>> value of an SD card, not completely but somewhat, of course, for those
>> in the previous thread who say it's of no value.  I had thought
>> otherwise, that it would be like the harddrive in a computer, easily
>> available after the computer failed***.
>
>Hard drives can be encrypted too. Although I think that's mainly used
>with user-supplied passphrases, I'd not be surprised if the DRM in TPM
>and "Secure computing" allowed for a similar thing.
>
>> I should also mention that, though the phone created a data subdirectory
>> for every app, all 220, and some of them had multiple subdirectories, it
>> took me a long time to check but none except for the photo/video
>> directory had more than 2 files, both under 100 bytes.   So only the
>> photos were saved there and only after I set some setting to save to the
>> SD card, for fear internal storage would fill up. 
>>
>> Of course the external storage is no worse than the internal storage
>> here, because it will be hard and probably impossible to get anything
>> out of internal storage now that the phone is broken.  It's not like a
>> computer , is it, where you can open it up and take out the storage, or
>> is it?
>>
>> ***Why *do* they encrypt the SD card and lock it to the phone? If they
>> didn't, it would be more useful after the phone failed.
>
>So that data cannot be extracted without permission? And perhaps to
>enforce non-rooted Android limitations too... (so this one would
>definitely be DRM too).

[toc] | [prev] | [next] | [standalone]

#155015

On 2026-08-15 16:23, micky wrote:
> In comp.mobile.android, on Sat, 15 Aug 2026 09:34:36 +0100, Nuno Silva
> <nunojsilva@invalid.invalid> wrote:


> Properties has all along said the SD card has no errors, but when I try
> to repair it anyhow, it says it can't.
> 
> Now, I can display the top level directory items, but when using an
> after-market file manager, PowerDEsk, I try to open any of the
> directories one level down, the file manager repositions at "PC" or some
> high place unrelated to the SD card.  When I use the MS file manager,
> this doesn't happen unless I try to open DCIM, which is where the photos
> are, but it happens that way when I try to open DCIM. (Inside that is
> Camera, and that has the photos.  It used to open but now doesn't even
> though I never tried to write to it.  I only read, and it copied 38+4%
> of the files.)
> 
> I will look into ddrescue that you mention, but I'm not optimistic.

ddrescue does no repair. It simply copies a disk or partition to another place, even if it finds errors when reading it.

For instance, the other day I tried to recover deleted photos on a card. First I cloned the card with 'dd', then I recovered the photos with PhotoRec (Linux), working on the image, instead of the card.

 From my notes:

         SystemRescueCd  http://www.system-rescue-cd.org/

         PhotoRec        recovers files from deleted memory cards (from cameras). 12 April 2009
                         http://www.cgsecurity.org/wiki/PhotoRec
         f3              http://oss.digirati.com.br/f3/          recovers/analyses USB sticks.



-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#155030

On 2026-08-15, Carlos E. R. wrote:

> On 2026-08-15 16:23, micky wrote:
>> In comp.mobile.android, on Sat, 15 Aug 2026 09:34:36 +0100, Nuno Silva
>> <nunojsilva@invalid.invalid> wrote:
>
>
>> Properties has all along said the SD card has no errors, but when I try
>> to repair it anyhow, it says it can't.
>>
>> Now, I can display the top level directory items, but when using an
>> after-market file manager, PowerDEsk, I try to open any of the
>> directories one level down, the file manager repositions at "PC" or some
>> high place unrelated to the SD card.  When I use the MS file manager,
>> this doesn't happen unless I try to open DCIM, which is where the photos
>> are, but it happens that way when I try to open DCIM. (Inside that is
>> Camera, and that has the photos.  It used to open but now doesn't even
>> though I never tried to write to it.  I only read, and it copied 38+4%
>> of the files.)
>>
>> I will look into ddrescue that you mention, but I'm not optimistic.
>
> ddrescue does no repair. It simply copies a disk or partition to
> another place, even if it finds errors when reading it.

Yes, but it is tailored for media with errors or reading difficulties,
and will let you know if there *are* errors.

> For instance, the other day I tried to recover deleted photos on a
> card. First I cloned the card with 'dd', then I recovered the photos
> with PhotoRec (Linux), working on the image, instead of the card.

Yeah, just for undeletion in a healthy medium, ddrescue isn't necessary,
although one might feel tempted just to get its progress display.

>
> From my notes:
>
>         SystemRescueCd  http://www.system-rescue-cd.org/
>
>         PhotoRec        recovers files from deleted memory cards (from cameras). 12 April 2009
>                         http://www.cgsecurity.org/wiki/PhotoRec
>         f3              http://oss.digirati.com.br/f3/          recovers/analyses USB sticks.

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#155038

On 2026-08-16 02:14, Nuno Silva wrote:
> On 2026-08-15, Carlos E. R. wrote:
> 
>> On 2026-08-15 16:23, micky wrote:
>>> In comp.mobile.android, on Sat, 15 Aug 2026 09:34:36 +0100, Nuno Silva
>>> <nunojsilva@invalid.invalid> wrote:
>>
>>
>>> Properties has all along said the SD card has no errors, but when I try
>>> to repair it anyhow, it says it can't.
>>>
>>> Now, I can display the top level directory items, but when using an
>>> after-market file manager, PowerDEsk, I try to open any of the
>>> directories one level down, the file manager repositions at "PC" or some
>>> high place unrelated to the SD card.  When I use the MS file manager,
>>> this doesn't happen unless I try to open DCIM, which is where the photos
>>> are, but it happens that way when I try to open DCIM. (Inside that is
>>> Camera, and that has the photos.  It used to open but now doesn't even
>>> though I never tried to write to it.  I only read, and it copied 38+4%
>>> of the files.)
>>>
>>> I will look into ddrescue that you mention, but I'm not optimistic.
>>
>> ddrescue does no repair. It simply copies a disk or partition to
>> another place, even if it finds errors when reading it.
> 
> Yes, but it is tailored for media with errors or reading difficulties,
> and will let you know if there *are* errors.

Ok, yes.

...

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#155039

This post is relevant to win10 and 11 . 


In comp.mobile.android, on Sun, 16 Aug 2026 01:14:50 +0100, Nuno Silva
<nunojsilva@invalid.invalid> wrote:

>On 2026-08-15, Carlos E. R. wrote:
>
>> On 2026-08-15 16:23, micky wrote:
>>> In comp.mobile.android, on Sat, 15 Aug 2026 09:34:36 +0100, Nuno Silva
>>> <nunojsilva@invalid.invalid> wrote:
>>
>>
>>> Properties has all along said the SD card has no errors, but when I try
>>> to repair it anyhow, it says it can't.
>>>
>>> Now, I can display the top level directory items, but when using an
>>> after-market file manager, PowerDEsk, I try to open any of the
>>> directories one level down, the file manager repositions at "PC" or some
>>> high place unrelated to the SD card.  When I use the MS file manager,
>>> this doesn't happen unless I try to open DCIM, which is where the photos
>>> are, but it happens that way when I try to open DCIM. (Inside that is
>>> Camera, and that has the photos.  It used to open but now doesn't even
>>> though I never tried to write to it.  I only read, and it copied 38+4%
>>> of the files.)
>>>
>>> I will look into ddrescue that you mention, but I'm not optimistic.
>>
>> ddrescue does no repair. It simply copies a disk or partition to
>> another place, even if it finds errors when reading it.
>
>Yes, but it is tailored for media with errors or reading difficulties,
>and will let you know if there *are* errors.
>
>> For instance, the other day I tried to recover deleted photos on a
>> card. First I cloned the card with 'dd', then I recovered the photos
>> with PhotoRec (Linux), working on the image, instead of the card.
>
>Yeah, just for undeletion in a healthy medium, ddrescue isn't necessary,
>although one might feel tempted just to get its progress display.
>
>>
>> From my notes:
>>
>>         SystemRescueCd  http://www.system-rescue-cd.org/
>>
>>         PhotoRec        recovers files from deleted memory cards (from cameras). 12 April 2009
>>                         http://www.cgsecurity.org/wiki/PhotoRec
>>         f3              http://oss.digirati.com.br/f3/          recovers/analyses USB sticks.

Just for a follow-up.  Use of windows 10 (because that box has a
full-size SD card reader in the front and the win11 only has a tiny slot
in the side hard to get to since my breakfast table is covered with
junk), use of win10 to copy the files was erratic, to put it mildly.    

Would win11 work better for this troublesome copying? 

I usually use PowerDesk but the only free copy is quite old now.  I
thought when I right clicked and did Properties, it would use the same
Properties program that MS File Explorer used, but the MS version has
too more tabs!!!!  Hardware and one other.   Maybe something about
PowerDesk means it can't implement those two tabs, can't relay the
information?

Anyhow, as I said, with Powerdesk I would go to the SD card, go to DCIM,
go to Camera, and then open all the photos and videos, and then it would
reposition at This PC.  So I tried the MS file explorer. 

Same thing, but after 5 times, the sixth time it didn't.  One time
stopped at the same 4% but continued a couple minutes later (a previous
and a later time I waited for an hour and it just stayed at 4%. 

One time it made it to 50%.  I would just copy what's left, but more
likely to freeze the window or reposition at This PC if I try to list
them.  More failures, reboot windows, more failures. 

One time only it said Cannot copy filename, and offered to skip it, but
like a fool I clicked on Retry.  And it just froze, never offered to
skip it again. 

All when I think I have 3 other copies of all these pictures. 

So I decide to format, and it refuses to do a non-quick format.  I do a
quick format and then it is wiling to do a non-quick format, which it
does at the appropriate slow pace.


But I think I'd be a fool to rely on this SD card, right?   I know
formating is supposed to find all the bad spots, and list their
locations so they are not used, but would you guys use this SD card for
anything important?   

[toc] | [prev] | [next] | [standalone]

#155040

On Sun, 8/16/2026 11:52 AM, micky wrote:

> But I think I'd be a fool to rely on this SD card, right?   I know
> formating is supposed to find all the bad spots, and list their
> locations so they are not used, but would you guys use this SD card for
> anything important?   

You have to know how a device works under the hood, to be
using trash-bunny techniques on it. Is it direct mapped, and
you can burn spots into it, or, is it "wear leveled static&dynamic".

   https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/

A lot of trash-bunny techniques, result in writes to a device.
It it is already on its way out, and in a spiral-of-death,
the activities might actually be accelerating the end of
the device.

As for the article, we've been baited before by all this talk
of wear leveling, and the game continues. It's hard to say
whether any quality TLC flash devices exist, as that's what
these pieces of shit will be made of. I looked at my computer
store listing, and you can't buy an 8GB MLC based one any more,
they're going to all be TLC or QLC. And they won't
actually tell you what kind of flash is in an SD.
"Buying new is not necessarily buying better"
Some of the older SD cards, are going to last longer.
Just because of the flash type.

This makes a good hobby though, and is slightly ahead of
stamp collecting. And as that Reddit thread shows, it has the
same amount of drama, for sure (the "talking with engineering" schtick
the tech support carried out). Companies and their tech support,
it's highly likely they don't even make the product themselves,
and it arrives in big burlap bags and they put their brand
sticker on it.

Summary: If you device isn't healthy... don't use it.

   Paul

[toc] | [prev] | [next] | [standalone]

#155046

In comp.mobile.android, on Sun, 16 Aug 2026 13:13:58 -0400, Paul
<nospam@needed.invalid> wrote:

>On Sun, 8/16/2026 11:52 AM, micky wrote:
>
>> But I think I'd be a fool to rely on this SD card, right?   I know
>> formating is supposed to find all the bad spots, and list their
>> locations so they are not used, but would you guys use this SD card for
>> anything important?   
>
>You have to know how a device works under the hood, to be
>using trash-bunny techniques on it. Is it direct mapped, and
>you can burn spots into it, or, is it "wear leveled static&dynamic".
>
>   https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/
>
>A lot of trash-bunny techniques, result in writes to a device.
>It it is already on its way out, and in a spiral-of-death,
>the activities might actually be accelerating the end of
>the device.
>
>As for the article, we've been baited before by all this talk
>of wear leveling, and the game continues. It's hard to say
>whether any quality TLC flash devices exist, as that's what
>these pieces of shit will be made of. I looked at my computer
>store listing, and you can't buy an 8GB MLC based one any more,
>they're going to all be TLC or QLC. And they won't
>actually tell you what kind of flash is in an SD.
>"Buying new is not necessarily buying better"
>Some of the older SD cards, are going to last longer.
>Just because of the flash type.
>
>This makes a good hobby though, and is slightly ahead of
>stamp collecting. And as that Reddit thread shows, it has the
>same amount of drama, for sure (the "talking with engineering" schtick
>the tech support carried out). Companies and their tech support,
>it's highly likely they don't even make the product themselves,
>and it arrives in big burlap bags and they put their brand
>sticker on it.
>
>Summary: If you device isn't healthy... don't use it.

I didn't understand most of what you wrote, but I bought a new SD card.
4x as big, too. 

Months ago you gave a suggestion in the android group, to turn off
gestures so that my phone woldn't light up when putting it in my pocket.
I'm positive I had done that but I checked and it wasn't set that way,
so I set it and was waiting for results to tell you if it worked or not.
At firs it seemed to say yes, but later results were a little mixed. And
of course now the phone is dead, so it will never be known for sure. 

Even though I figured Xiaomi fixed the problem in the 7 years since the
last phone, it was still a factor in my being ready to buy a different
brand.   

The last phone's screen turned on when I didn't want it to, and turned
off when it was plugged into the car charger, even when I was looking at
a map and wanted it on all the time.  It did not turn off when I was
folling the map's directions, but that was not enough.  I installed a
couple apps that said it would keep the screen on, one that went by app
(and I set it for all the map apps) but it didnt' work either.   :-)
Hard to write for so many different implementations. 

If the new phone fixes one of these, it will be an improvement. If both
of them, it will be miraculous. 


>   Paul

[toc] | [prev] | [next] | [standalone]

#155047

On Sun, 8/16/2026 9:26 PM, micky wrote:
> In comp.mobile.android, on Sun, 16 Aug 2026 13:13:58 -0400, Paul
> <nospam@needed.invalid> wrote:
> 
>> On Sun, 8/16/2026 11:52 AM, micky wrote:
>>
>>> But I think I'd be a fool to rely on this SD card, right?   I know
>>> formating is supposed to find all the bad spots, and list their
>>> locations so they are not used, but would you guys use this SD card for
>>> anything important?   

>>   https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/>>
>> Summary: If you device isn't healthy... don't use it.
> 
> I didn't understand most of what you wrote, but I bought a new SD card.
> 4x as big, too. 

The Reddit thread, mentions an SD Association utility for
working on an SD. The people in the thread claim, it
"changes the device capacity", which means a block of flash
is getting disabled, or there is some mechanism other
than $BADCLUS, for marking off bits of the device.

But if one section of device fails, what condition are
the other sections in ? Should we take a chance on that ?

It is the same chance we take, when moving a partition
on a hard drive, to the "unworn" part of the disk. Is
that a good idea ? There, you rely on your field
statistics. Drives can hold on for a good long time,
and if you are babying the device, you can actually
note the thing going downhill. (For example, I could
see 300 reallocations after a major data change on the disk.)
You can stop using the device, if you know when it is
going to cut out. I actually followed a hard drive
downhill, until its functional status changed. If
the reallocated max is 5500 sectors, the device stops
working at exactly half that number. You're not
allowed to do any more writes to the disk, once
it gets to half of that number. You don't actually
have 5500 to burn up. And I ruined a device on purpose,
to get that information.

If you're using a storage device, and the behavior
is known, maybe you can "use them up" like that, and
transfer off just before they crash for good.

If on the other hand, there isn't enough data to tell
you how the thing is working, then replacing it promptly
is also an option.

If you buy one with Wear Leveling, it should last a lot
longer. The SD is unlikely to have a TRIM command, so
this means the internal TRIMming is done by some other
(not as good) technique. That's also a feature of SSDs.
If your OS does not send TRIM commands, that's OK,
as the device has a fall back it uses internally.

     600  590  580  585  590      Average about ~585 or so, of write cycles
     blk  blk  blk  blk  blk      Maybe weekly TRIM helps with this

     600  550  575  565  590      Maybe the average is a bit lower...
     blk  blk  blk  blk  blk      when the internal mechanism is used

600 is a location that is "worn out" (600 write cycles).

The other locations are less worn. If we discarded the second
device there, the 550 location, we have 50 writes remaining for that
block (that's if the device would even talk to us, the assumption is
that it has stopped working).

TRIM uses knowledge of where actual files are stored, to "tell"
the storage device, which locations do not require flash backing and
can go back into the "free pool" of blocks.

When the internal mechanism is used, and no TRIM commands
tell the drive the situation, the drive can still manage some
amount of leveling, just not as good as with TRIM.

Without any wear leveling at all, if you keep writing the
MBR sector over and over and over again, the MBR fails first,
and gobs of potential write capability are thrown away when
the device is tossed in the garbage. That's how my
dead USB sticks treated me. A spot burned into them apparently,
and the devices, unrecoverable. A $3 stick, does not wear level.

   Paul

[toc] | [prev] | [next] | [standalone]

#155048

On Fri, 14 Aug 2026 22:37:01 -0400, micky <NONONOmisc07@fmguy.com>
wrote:

>In comp.mobile.android, on Fri, 14 Aug 2026 20:33:21 -0500, VanguardLH
><V@nguard.LH> wrote:
>
>>Mike Easter <MikeE@ster.invalid> wrote:
>>
>>> I do not use cell phones conventionally; I don't carry a phone, I don't 
>>> normally even turn a phone on. I just now subscribed to this group to 
>>> ask a question, but I haven't read any recent msg threads here.
>>> 
>>> I have an old cellphone w/ Android 6 and no cell plan which I use for 
>>> various purposes via wifi, camera, & music. I have a newer tablet phone 
>>> which does have a plan which I use occasionally via wifi.
>>> 
>>> I am fairly ignorant of navigating my old cellphone's features, which is 
>>> why I'm here now.
>>> 
>>> Whenever I start the phone, I'm informed about how low the 8G internal 
>>> storage is. I only recently changed the settings to use the 32G SD card 
>>> by default instead of internal.
>>> 
>>> My problem is that I can't find a way to 'get rid of' any data in 
>>> internal storage that is causing my low storage condition.
>>> 
>>> The online advice I've found hasn't been helpful to me.
>>
>>My guess is you are asking about the Adoptive Storage feature.  Once you
>>adopt the SD card to augment your phone's internal storage, everything
>
>Are SD cards always adopted like this, or acn they be used without
>encryption and locking? 

I've never "adopted" a card like this, and always used them for data
storage, which I can copy to computers etc. 

My first Android phone had 1Gb of main storage, and soon ran out of
space for photos, sound recordings etc. 



-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://methodius.blogspot.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[toc] | [prev] | [next] | [standalone]

#154986

Mike Easter wrote:
> Whenever I start the phone, I'm informed about how low the 8G internal 
> storage is. I only recently changed the settings to use the 32G SD card 
> by default instead of internal.
> 
> My problem is that I can't find a way to 'get rid of' any data in 
> internal storage that is causing my low storage condition.

I've improved my situation. My problem before was that 'everywhere I 
looked' I could not find any stored data to delete. So I decided to 
uninstall apps which I had no use for, particularly those which were in 
Mb instead of kb. A number which had Mb usage which could NOT be 
uninstalled I learned should/could be disabled instead of uninstalled 
and recover internal.

Doing all that managed to free up more than a gig, which turns out to be 
very helpful in an 8G device that was using almost all that to just boot.

I have 2 8G desktops (both principally running linux/es or occsly W7) 
which don't need to use anywhere near their 8G; I don't see why the 
android needs to 'use' 8G before it even does anything.

I also have an old RPi 3B running Raspbian which only has 1G and I can 
do 'all I want to do' with it, being 'respectful' of not engaging in 
ram-eating behaviors.

-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#154991

On 2026-08-15, Mike Easter wrote:

> Mike Easter wrote:
>> Whenever I start the phone, I'm informed about how low the 8G
>> internal storage is. I only recently changed the settings to use the
>> 32G SD card by default instead of internal.
>>
>> My problem is that I can't find a way to 'get rid of' any data in
>> internal storage that is causing my low storage condition.
>
> I've improved my situation. My problem before was that 'everywhere I
> looked' I could not find any stored data to delete. So I decided to
> uninstall apps which I had no use for, particularly those which were
> in Mb instead of kb. A number which had Mb usage which could NOT be
> uninstalled I learned should/could be disabled instead of uninstalled
> and recover internal.
>
> Doing all that managed to free up more than a gig, which turns out to
> be very helpful in an 8G device that was using almost all that to just
> boot.

On an older-than-that Samsung Android, clicking the "space is running
low" notification opens the part of the settings that shows the storage
usage. I think at least some of the items there can be clicked further
to open another appropriate components (I think the installed
application list is one of them).

I have a somewhat similar situation (said phone is quite full, I need to
move things from internal storage to another µSD card), but at least in
my case I know it's mainly photos and videos, which I stopped moving
often to the desktop as I started having trouble with MTP.

> I have 2 8G desktops (both principally running linux/es or occsly W7)
> which don't need to use anywhere near their 8G; I don't see why the
> android needs to 'use' 8G before it even does anything.
>
> I also have an old RPi 3B running Raspbian which only has 1G and I can
> do 'all I want to do' with it, being 'respectful' of not engaging in
> ram-eating behaviors.

... wait, are we talking *non-volatile* data *storage* or RAM?

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#155012

Nuno Silva wrote:
> ... wait, are we talking*non-volatile* data*storage* or RAM?

Sorry; I was smearing it all together, 'confusingly'.

The phone in question has 1G (0.94) ram, 8G (6.52 used) internal storage 
+ 32G (1.2 used) SD card.

Booted, now the phone has 250 meg ram free and 1.5G internal storage 
available, and almost all of the SD card's.

-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#155014

Mike Easter wrote:
> Booted, now the phone has 250 meg ram free and 1.5G internal storage 
> available, and almost all of the SD card's.

Below is astoundingly excellent advice, which, oh, I'd wager only one in a
million (or maybe one in ten million) people can even understand why.

The very first thing most people do, and in fact, most camera apps do, is
set the external sdcard as the location to put camera images and videos.

What I suggest you do, but knowing you're much like Vanguard, Steve Hayes,
s|b, Rudy Weiser and Mayayana, et al., I suspect you won't understand why I
suggest it, is format the sd card to a known easily remembered set such as
       0000-0001

The *reason* I suggest that, is many apps (not all, but many) will
reference the sdcard as /0000-0001 after the volume name you gave it.

If you don't format the volume name, then you end up with random characters
such as /AF2D-F41B which is *much harder* to remember when you need it.

The third thing I would suggest you do, and I suggest this not so much for
you but for everyone lurking to benefit from the largesse of my knowledge, 
is to put on your internal storage a directory named something obvious like
  0 (or 00 or 000 or 0000 or whatever, but starting with zero).

Then, the fourth thing is to create a similar directory on the sd card of
  1 (or 01 or 001 or 0001 or whatever, but starting with one).

Trust me on my knowledge, which exceeds yours, that there are good reasons
for doing so, where the fifth thing I suggest, to make it all work
together, is to put *all* your important files into *only* those folders.

Why?

Because the nature of Android, much like the nature of Windows, is to
pollute the user folders that it knows about so badly they become a swamp.

These folders that you've created, 0 for the internal storage and 1 for the
external storage, will *never* be polluted because they're non-standard.

So, for example, you put your map databases in /0000-0001/0001/maps/.
And, for example, you put your PDF files in /0000-0001/0001/docs/pdfs/.
etc.

If it's something you need even when the sd card is removed, then you put
it in the internal storage, but always in the folder that control.

For example, your encrypted passwords might go into internal storage under
 /0000/vipw/keepassdx.dbx

The astounding beauty of this philosophy is you can tell, instantly which
sd card you're looking at (which isn't as easy as you might think,
especially when using adb non-graphical interfaces) and more importantly,
to back up your *important data* you only need to back up two directories.
 1. Back up the 0000 folder on the internal sdcard
 2. Back up the 0001 folder on the external sdcard

Once you back up those two folders, your backup is complete.

Again, I realize most of this will be lost on you, but I invest the energy
to be purposefully helpful not only to help you, but to help many others.
-- 
Once we understand the complexities, the whole thing becomes very simple.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.mobile.android

csiph-web