Windows format doesn't completely change sdcard volume name for Android use

[Marion]

The more I do to improve efficiency between Android and Windows, and
specifically to make inevitable porting of each completely seamless,
the more I learn how complex it gets when you are dealing with sdcards.
<Loading Image...>

When you mindlessly double your portable memory, you end up with the new
filespec being different than the old filespec due to the new volume name.
<Loading Image...>

In order to make seamless the doubling of sdcard portable memory, I have,
for years, Windows-formatted the new volume label to match the old name.
<Loading Image...>

That clever little trick wonderfully enables the filespec for the new
sdcard portable memory to be the same as the old for Android apps.
<Loading Image...>

Even Windows calls uses the new volume name, which is nicely consistent
such that paths to map data on Windows are the *same* as on Android.
<Loading Image...> OsmAnd~ Windows confirmation
<Loading Image...> OsmAnd~ Android confirmation

With the result that doubling portable storage is entirely seamless to all
your Windows/Android apps whether they be editors or maps or file managers.
<Loading Image...>>

However... with all magic... comes complexity (of understanding)...

In another thread, an offshoot revealed that even if you change the volume
name (aka volume label) of your portable storage sdcard, while Android apps
can use either the old volume name or the new volume name (apparently), the
question is why didn't Windows format *completely* change the Volume Name?
*Clever helpful suggestion for portable memory using Windows & Android editors*
<https://www.novabbs.com/computers/article-flat.php?id=57086&group=comp.mobile.android#57086>

As a result, Android file managers sometimes display only the new name:
<Loading Image...>

And some Android file managers only display the old volume name:
Loading Image...>

Yet, more often than not, Android file managers display both volume names!
<Loading Image...>
<Loading Image...>
<Loading Image...>

Why?
Does anyone know what is going on to explain the recent observations above?

[R.Wieser]

Arlen,

the question is why didn't Windows format *completely* change the Volume
Name?

You're missing the, rather obvious, other possibility :

Its not that Windows didn't completely change the volume name (where would
Windows store the old one ? Have you checked ?), its Android which is doing
something to show the old name.

I leave it up to you to research what that it is.

Hint: Isn't there something on the SD card which you *can't* change ? Whats
the chance that that is involved ?

Regards,
Rudy Wieser

[Carlos E.R.]

On 2025-02-04 21:28, Marion wrote:

...

Post by Marion
However... with all magic... comes complexity (of understanding)...
In another thread, an offshoot revealed that even if you change the volume
name (aka volume label) of your portable storage sdcard, while Android apps
can use either the old volume name or the new volume name (apparently), the
question is why didn't Windows format *completely* change the Volume Name?

No, it is not the old label, but the UUID, which in Windows is kept
short, not using the 128 bits. It is possibly the same as the label, or
at least in the same style.

For instance, in Linux you can use "tune2fs" to write the uuid of an
ext4 partition.

-U UUID
Set the universally unique identifier
(UUID) of the file system to UUID. The
format of the UUID is a series of hex
digits separated by hyphens, like this:
"c1b9d5a2-f162-11cf-9ece-0020afc76f16".
The UUID parameter may also be one of
the following:

clear clear the file system UUID

random generate a new randomly-gen-
erated UUID

time generate a new time-based
UUID

The UUID may be used by mount(8),
fsck(8), and /etc/fstab(5) (and possibly
others) by specifying UUID=uuid instead
of a block special device name like
/dev/hda1.

See uuidgen(8) for more information. If
the system does not have a good random
number generator such as /dev/random or
/dev/urandom, tune2fs will automatically
use a time-based UUID instead of a ran-
domly-generated UUID.


So, the Windows format command should create the uuid randomly, and
perhaps allows to change it.


I suggest you find a command to at least display the uuid in Windows,
and then format an usb mem stick to check what happens to it.


Maybe here:
<https://stackoverflow.com/questions/70770357/how-can-i-get-the-guid-of-my-disc-partitions>

There is a sample code using Delphi, and some possibilities using the
Power Shell.