From Newsgroup: comp.editors

Below is both a clever suggestion - and - a quizzical question.

Here's the problem set (which I experienced myself, recently):
A. You're a typical Android/Windows/editor owner with a 64GB sdcard
B. Most of your editing data is kept on that 64GB portable memory card
C. But then you need to double your memory (to 128GB, which costs ~$10)

What happens?
Well, for most people, they lose many editing associations to the files.

Why?
Because for many editors, they don't "search" for file associations.
Coupled with the filespec having changed between the 64GB & 128GB sd cards.

Huh?
You need to know that every sdcard comes with a "volume name".
An example volume name could be, for example, "A1B1-C1D1" (or whatever).
Another example volume name could be, for example, "A2B2-C2D2".

The point is that every sdcard comes with an (almost) unique volume name.
So?

Well, the old card filespec to your data is now *different* than the new!
OLD: /storage/A1B1-C1D1/{editors}/{files}
NEW: /storage/A2B2-C2D2/{editors}/{files}

OK. That sucks. So now you have to manually re-establish the filespec.
For every modern editor. For every file that the editor associates with.

Why did you insert "modern" editor in that sentence?
Are you being sneaky?

Well, a good editor will save its own files wherever you want them to be.
Some editors are good (such as map editing programs, for example).

Those good (aka modern) editors will access your files on the sdcard.
Just like cameras do (but cameras have another trick up their sleeve).
Cameras will *find* all their "media" files, so they don't have this issue.

But many editors do have this issue - particularly map editors.
And GPX editors. And PDF editors. And text editors. (and so on)

So what's the trivially simple (yet devilishly clever) solution then?
Heh heh heh... it's so simple - it should be outlawed as too simple.

Simply format your new sdcard to the same volume name as the old sdcard.
Yup. It's that simple.

STEP 1: Determine the old 64GB sd card volume name (e.g., 0000-0001).
STEP 2: On Windows, quick format the new 128GB sd card to the same name.
STEP 3: On Windows, copy all the old data to the new 128GB sd card.

That's it!
You pop in the new sdcard and everything works exactly as it should.
Ask me how I know that this concept of "portable memory" just works.

Now... for my quizzical question, where the problem set is similar:
A. You're a typical HP Stream owner with a permanent 32GB C: drive
B. So you've added a 64GB portable memory card as the D: drive
C. But then you need to double the D: drive (to 128GB, which costs ~$10)

Does the same trick of formatting the volume name work in that scenario?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Marion wrote:

A. You're a typical HP Stream owner with a permanent 32GB C: drive
B. So you've added a 64GB portable memory card as the D: drive
C. But then you need to double the D: drive (to 128GB, which costs ~$10)

Does the same trick of formatting the volume name work in that scenario?

I would expect that as long as the laptop sees the new SD card as D:\
drive, nothing will really care ...
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <m04lg5Famh9U1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:

Marion wrote:

A. You're a typical HP Stream owner with a permanent 32GB C: drive
B. So you've added a 64GB portable memory card as the D: drive
C. But then you need to double the D: drive (to 128GB, which costs ~$10)

Does the same trick of formatting the volume name work in that scenario?

I would expect that as long as the laptop sees the new SD card as D:\
drive, nothing will really care ...

Arlen is very good at dreaming up non-problems, and then dreaming up "solutions" to those non-problems.
--
On the subject of racism being depicted in the media, the far right and the far left have
met up in agreement (sort of like how plus infinity meets up with minus infinity).
The far left doesn't want it, because they are afraid it will make people racist.
The far right doesn't want it, because they are afraid it will make people feel bad about being racist.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Fri, 31 Jan 2025 19:26:54 -0000 (UTC), Kenny McCormack wrote :

very good at dreaming up non-problems

The main point of this thread was to purposefully helpfully inform people
of the rather useful approach of formatting the volume label of sd cards.

I have tested two scenarios, both of which work perfectly when you change
out the sd card - but only if you've matched their respective volume labels
1. When you move from phone a to phone b where b is a clone of a, and,
2. When you double (or triple, or whatever) the size of the memory card.

Having said that the most important point in this thread is that...

I realize Kenny McCormack is a common troll, but the point that shouldn't
be lost when these trolls try to waste our time is that formatting the new
sd card with the same name as the old sd card is a rather useful approach.

For media, in general, it doesn't matter if you copied your old DCIM folder from your 64GB sd card to your new sd card, but for most modern editors
(which can store files on the external portable memory card), it does
matter.

A classic example these ignorant trolls like Kenny McCormack don't
understand is the case of OSM map editors, which can store their *huge* map (and other associated KML, GPX, etc.) databases on the external sd card.

When you double the size of your portable memory, the existing installed editors such as OSMAnd~ don't even realize the card was swapped out on it.

Likewise for most modern editors. They still find their external files, but only if you've thought ahead by matching the entire filespec exactly.

Interestingly, what does seem to work even without matching the volume
label, is "media files" tend to be found even when the volume label changes (which I suspect is due to a file-type tag that the operating system adds).

Does anyone have more detail on how that file-type tag works in the
specific case of switching from one filespec to another in the volume label when a typical user (who doesn't know the trick) inserts a new sd card?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-01-31 22:18, Marion wrote:

On Fri, 31 Jan 2025 19:26:54 -0000 (UTC), Kenny McCormack wrote :

very good at dreaming up non-problems

The main point of this thread was to purposefully helpfully inform people
of the rather useful approach of formatting the volume label of sd cards.

It would be clever if you used the label command instead of format :-p

I have tested two scenarios, both of which work perfectly when you change
out the sd card - but only if you've matched their respective volume labels 1. When you move from phone a to phone b where b is a clone of a, and,
2. When you double (or triple, or whatever) the size of the memory card.

Having said that the most important point in this thread is that...
I realize Kenny McCormack is a common troll, but the point that shouldn't
be lost when these trolls try to waste our time is that formatting the new
sd card with the same name as the old sd card is a rather useful approach.

I disagree. It is useful for your scenario, it is not for my scenarios.

For media, in general, it doesn't matter if you copied your old DCIM folder from your 64GB sd card to your new sd card, but for most modern editors (which can store files on the external portable memory card), it does
matter.

A classic example these ignorant trolls like Kenny McCormack don't
understand is the case of OSM map editors, which can store their *huge* map (and other associated KML, GPX, etc.) databases on the external sd card.

When you double the size of your portable memory, the existing installed editors such as OSMAnd~ don't even realize the card was swapped out on it.

Likewise for most modern editors. They still find their external files, but only if you've thought ahead by matching the entire filespec exactly.

Not so. You can use relative paths.

Interestingly, what does seem to work even without matching the volume
label, is "media files" tend to be found even when the volume label changes (which I suspect is due to a file-type tag that the operating system adds).

Does anyone have more detail on how that file-type tag works in the
specific case of switching from one filespec to another in the volume label when a typical user (who doesn't know the trick) inserts a new sd card?

--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <2suv6lxdht.ln2@Telcontar.valinor>,
Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-01-31 22:18, Marion wrote:

On Fri, 31 Jan 2025 19:26:54 -0000 (UTC), Kenny McCormack wrote :

very good at dreaming up non-problems

The main point of this thread was to purposefully helpfully inform people
of the rather useful approach of formatting the volume label of sd cards.

It would be clever if you used the label command instead of format :-p

That was my immediate thought as well.
--
John Steinbeck: "Socialism never took root in America because the poor
see themselves not as an exploited proletariat but as temporarily
embarrassed millionaires."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Carlos E.R. wrote:

It would be clever if you used the label command instead of format Efyc

Are we discussing the label, or the volume ID?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <m050veFcalhU2@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:

Carlos E.R. wrote:

It would be clever if you used the label command instead of format

Are we discussing the label, or the volume ID?

I assume the former, because I don't think the DOS/Windows "format" command allows you to set the UUID or PARTUUID. Arlen's ideas are based on using DOS/Windows "format" to make the change.
--
People often ask what is the difference between liberals and conservatives.
It is this. Libs see the government helping them and are OK with the government also helping other people. Cons see the government screwing them and are OK with that as long as the government is also screwing other people.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-01-31 23:25, Andy Burns wrote:

Carlos E.R. wrote:

It would be clever if you used the label command instead of format Efyc

Are we discussing the label, or the volume ID?

He said label :-)
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <j2007lx7q3.ln2@Telcontar.valinor>,
Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-01-31 23:25, Andy Burns wrote:

Carlos E.R. wrote:

It would be clever if you used the label command instead of format

Are we discussing the label, or the volume ID?

He said label :-)

When it says Libby's Libby's Libby's on the label label label...
--
Just like Donald Trump today, Jesus Christ had a Messiah complex.

And, in fact, the similarities between the two figures are quite striking.
For example, both have a ragtag band of followers, whose faith cannot be shaken.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Fri, 31 Jan 2025 22:48:45 -0000 (UTC), Kenny McCormack wrote:

When it says Libby's Libby's Libby's on the label label label...

This fucking troll McCormack has already infested all the political
newsgroups and now he's infecting this group with his troll rot.

From: Kenny McCormack <gazelle@shell.xmission.com>
Newsgroups: alt.global-warming,alt.home.lawn.garden,alt.home.repair,sac.politics,talk.politics.guns
Subject: Besides being completely wrong on the facts, your logic sucks, too Date: Mon, 21 Oct 2024 13:31:24 -0000 (UTC)
Organization: The official candy of the new Millennium
Message-ID: <vf5l3c$3g545$1@news.xmission.com>

In article <WexmTqqSkCMaqmqkqLqPrxNUzmCylASM@news.usenet.farm>,
Jamaal Bowman <jamaal.bowman@dumpster-fire.guv> wrote:
...

The dictator Democrats keeping chanting "democracy" yet the hypocrite
overlords never allow We the People to decide for ourselves.

It is the Trumprepublicans who are the authoritarians, not the Democrats. Just look at Project 2025. Or any rational analysis of the American political parties and their stances.

But that aside, it is pretty clear that people like you simply should not
be allowed to make your own choices. You are a hazard to yourself and others. You probably voted for the Orange Monster (and probably more than once). That in and of itself shows you're not competent to be in the
voting booth. I'm serious about this; you are clearly voting against your own interests.

Die fucking troll, Die.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Fri, 31 Jan 2025 22:25:50 +0000, Andy Burns wrote :

It would be clever if you used the label command instead of format 0a+0+c

Are we discussing the label, or the volume ID?

Hi Andy,

The terminology should be obvious from the context of the original post, although I can't say what Carlos was talking about - but take a look here
<https://i.postimg.cc/SKXTMVfx/sdcard04.jpg>

The problem we're solving here is most people don't know the clever trick.
So they end up, at best, doing wasteful labor intensive work such as this:
<https://i.postimg.cc/nr8KNVby/sdcard06.jpg>
<https://i.postimg.cc/mrzHRxwB/sdcard07.jpg>
<https://i.postimg.cc/vZ1RtXhc/sdcard08.jpg>

If only they knew the clever trick suggested in this thread.
Then they wouldn't have to do *anything* at all - as then it just works!
<https://i.postimg.cc/QN6nY1H5/sdcard09.jpg>
<https://i.postimg.cc/dtVcLJTR/sdcard10.jpg>
<https://i.postimg.cc/zD9P15FX/sdcard11.jpg>

Even better, the entire sd card is auto-mounted as a Windows drive!
<https://i.postimg.cc/ZK4pNMTx/sdcard12.jpg>

That way your Windows scripts work perfectly on your Android phone. Particularly the quick daily backup of all the robocopy delta files.

As for precise terminology, take a look at these previous answers:
<https://i.postimg.cc/900ZKSGZ/sdcard14.jpg>
<https://i.postimg.cc/sD84dVHX/sdcard15.jpg>

I hope that answers your question from the OP's standpoint.

The main goal was to help people efficiently double their memory,
without having to go through any process whatsoever of porting.

It's so simple, and yet so useful, it should be illegal. :)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Fri, 31 Jan 2025 23:39:47 +0100, Carlos E.R. wrote :

Are we discussing the label, or the volume ID?

He said label :-)

Hi Carlos,

I love your suggestion because it allows us to always add more value.
As the entire point of being on Usenet is to learn & disseminate value.

SD card terminology confuses people because there are at least 3 terms:
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

Some can be changed by the user and some can't be changed by the user.
But what matters is only what the software sees on the Android phone.

Particularly the filespec when you double the external memory size.
But I do agree with you that the terms can be confusing to some people.

Here's an old output from Gemini which helped explain the differences:
<https://i.postimg.cc/8cYnsxDm/sdcard17.jpg>

1. Volume ID (CID):

Purpose: This is the most fundamental and permanent identifier of the
SD card. It's a unique code programmed into the card's hardware by the manufacturer.
Format: A 128-bit (16-byte) code, often represented in hexadecimal.
How it's assigned: Assigned by the SD card manufacturer and cannot be changed by the user.
How it's used: Used for low-level identification and tracking of the SD card at the hardware level. It's crucial for card authentication and
security.
User-changeable? No, this is locked by the manufacturer.

2. Volume Serial Number:

Purpose: A unique numerical identifier for the SD card volume
(partition). Think of it as a fingerprint for that specific formatted
instance of the card.
Format: A 32-bit number, usually displayed as 8 hexadecimal characters (e.g., A1B2C3D4).
How it's assigned: Generated when the SD card is formatted. It can
change if you reformat the card.
How it's used: Primarily used by the operating system for internal identification and tracking of the SD card volume. You might see it in
system tools or when using command-line prompts.
User-changeable? Yes, you can change the volume serial number using third-party software like AOMEI Partition Assistant, or by formatting the
card.

3. Volume Name (or Label):

Purpose: A user-friendly name that you assign to the SD card volume.
It's like giving your SD card a nickname.
Format: A string of characters (letters, numbers, spaces) that you
choose.
How it's assigned: You set the volume name when you format the card or later through the operating system's file manager.

How it's used: Displayed in File Explorer (Windows) or Finder (Mac) to help
you easily identify your SD card.
User-changeable? Yes, you can easily change the volume name at any time
through the operating system's file manager.

Key Differences:

Permanence: The Volume ID (CID) is permanent, while the Volume Serial Number and Volume Name can be changed.
Level: The Volume ID is at the hardware level, while the Volume Serial Number and Volume Name are at the software (file system) level.
Purpose: The Volume ID is for secure identification, the Volume Serial Number is for system tracking, and the Volume Name is for user convenience.

Analogy:

Imagine a library:

The Volume ID (CID) is like the library's unique registration number
for the book. It's permanent and unchangeable.
The Volume Serial Number is like the barcode on a specific copy of the book. It's unique to that copy and might change if the copy is replaced.
The Volume Name (Label) is like the title of the book. It's
user-friendly and helps you find the book you're looking for.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Marion wrote:

SD card terminology confuses people because there are at least 3 terms:
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

Some can be changed by the user and some can't be changed by the user.
But what matters is only what the software sees on the Android phone.

Take into account, my first Android device (Nexus1) had a microSD slot,
which it certainly needed due to only having 512MB of onboard flash and
512MB of RAM, so plenty of swapfile and moving parts of the system to SD
... but no phone I've owned since then has had a card slot.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-01 07:03, Marion wrote:

On Fri, 31 Jan 2025 23:39:47 +0100, Carlos E.R. wrote :

Are we discussing the label, or the volume ID?

He said label :-)

Hi Carlos,

I love your suggestion because it allows us to always add more value.
As the entire point of being on Usenet is to learn & disseminate value.

SD card terminology confuses people because there are at least 3 terms:
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

You can change them in Linux.

Going from memory, one of them you change in the partitioner (fdisk).
This one was crucial with Windows 7 because M$ would use it to detect
machine change or pirated copy.

All these changes can be done without formatting and losing the content.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 31.01.2025 18:48, Marion wrote:

Below is both a clever suggestion - and - a quizzical question.

Here's the problem set (which I experienced myself, recently):
A. You're a typical Android/Windows/editor owner with a 64GB sdcard
B. Most of your editing data is kept on that 64GB portable memory card
C. But then you need to double your memory (to 128GB, which costs ~$10)

What happens?
Well, for most people, they lose many editing associations to the files.

Why?
Because for many editors, they don't "search" for file associations.
Coupled with the filespec having changed between the 64GB & 128GB sd cards.

Huh?
You need to know that every sdcard comes with a "volume name".
An example volume name could be, for example, "A1B1-C1D1" (or whatever). Another example volume name could be, for example, "A2B2-C2D2".

The point is that every sdcard comes with an (almost) unique volume name.
So?

Well, the old card filespec to your data is now *different* than the new! OLD: /storage/A1B1-C1D1/{editors}/{files}
NEW: /storage/A2B2-C2D2/{editors}/{files}

OK. That sucks. [...]

(I probably shouldn't engage in this thread - and not only because it
got aggressive recently - because it seems (partly?) a Windows issue,
given the mention of 'C:', 'D:' and such crap later in this thread;
but I'm curious...)

First, the above mentioned IDs have a purpose, I think; to uniquely
*identify* a hardware device.[*] (Please correct me if I'm wrong.) -
So it therefore sounds strange to change that ID in the first place.
And therefore it wouldn't appear to me to re-label that device and
even less to reformat the device just to change its "label".[**]

What I typically see as "solution" - but which is rather more of a
"concept" - is to use generic path components where you want them;
on Unix-like systems you'd create for example a symbolic link like
/storage/generic -> /storage/A2B2-C2D2
and generally access the files only through the generic link
/storage/generic/{editors}/{files}
If you want to replace the storage device just re-link the generic
link to the new device (and without any necessity to change device
identity).

(I'm not sure this is "clever" or "helpful" (as your suggestion is,
according to your subject), but it appears much more sensible to me.
Isn't that possible on Windows and Android to preserve portability?)

Janis

[*] I, and the OS, should actually have an interest to know whether
there's another (or new) device in the system.

[**] A quick browse of the Net shows that you could [on Windows] also
just simply change that label by context menu 'properties'.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <vnletd$5l96$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

(I probably shouldn't engage in this thread - and not only because it
got aggressive recently - because it seems (partly?) a Windows issue,
given the mention of 'C:', 'D:' and such crap later in this thread;
but I'm curious...)

Calling drive letters "crap" isn't "aggressive" ?

Anyway, given that this is a cross-posted thread, it would be useful to
know from which group you are reading/responding. I often give this info myself when responding to cross-posts.

My guess it that, like me, you are reading in comp.editors. The point of
this observation is that this thread (whatever it does eventually turn out
to really be about) is really more of an Android/Windows thing, and is only tangentially related to editors. If you're coming from a primarily Unix
(aka, Linux) background, a lot of it will look weird. I don't understand
it myself, but I am inferring (just from reading this thread) that there
are weirdnesses in both Android and Windows that give rise to the issues
that Arlen is trying to address.

Neither you nor I are familiar with these weirdnesses and problems, because
we both come primarily from Unix/Linux backgrounds - where such things
simply don't exist.
--
"They say if you play a Microsoft CD backwards, you hear satanic messages.
Thats nothing, cause if you play it forwards, it installs Windows."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 16:34:03 +0100, Janis Papanagnou wrote :

(I probably shouldn't engage in this thread - and not only because it
got aggressive recently

Kenny McCormack is the obvious off-topic troll whom you can thank for that.

When you throw out Kenny McCormack's trolling, you can then notice this
thread is about elegant planning, years ahead, for Windows playing a key
role in migrating Android editors from one device (or card) to another.

- because it seems (partly?) a Windows issue,
given the mention of 'C:', 'D:'

The idea is brilliant - as it involves migrating Android file editors years ahead of time using the key features that Windows possess.

and such crap later in this thread;
but I'm curious...)

Other than Kenny McCormack's purposefully unhelpful common trolling, there
is no 'crap' here.

In fact, there are 3 exquisitely related issues, which most people (likely) don't realize (perhaps) because most people haven't (apparently) ever even
once in their lives bothered to plan years ahead for platform migration, particularly how Windows plays a role in migrating Android editors.

First, the above mentioned IDs have a purpose, I think; to uniquely *identify* a hardware device.[*] (Please correct me if I'm wrong.) -

In another post in this thread, outside of Kenny McCormack's childish
trolling that is, we covered in gory detail the 3 sd card identifiers,
their (stated) purpose & on which platforms you can change them.
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

Bear in mind the enticing goal isn't to just change them, which I'm sure everyone except that common troll understood, but to ensure a clean
migration years in the future for the files that Android editors edit.

So it therefore sounds strange to change that ID in the first place.
And therefore it wouldn't appear to me to re-label that device and
even less to reformat the device just to change its "label".[**]

In stark contrast to Kenny McCormack's purposefully disruptive repetitive attempts at common trolling, it's refreshing you are intelligently
inquiring as to WHY (almost) everyone who owns Android with an sdcard (&
who owns Windows plus a few Android editors) would greatly benefit from changing the Volume Name (also well known completely interchangeably as the Volume Label).

What I typically see as "solution" - but which is rather more of a
"concept" - is to use generic path components where you want them;
on Unix-like systems you'd create for example a symbolic link like
/storage/generic -> /storage/A2B2-C2D2
and generally access the files only through the generic link
/storage/generic/{editors}/{files}
If you want to replace the storage device just re-link the generic
link to the new device (and without any necessity to change device
identity).

This was brought up prior, I think by Carlos if I remember correctly, where
I restrained myself from incredulously asking HOW he proposed to do that symlinking on Android such that the all-important Android file editors
would still recognize a path that has completely changed out from under
them.

To be clear, I'm absolutely and emphatically NOT saying it can't be done;
nor am I even intimating that it's not a great idea - I'm only asking, eyes wide open with intrigue, HOW you (and Carlos) would accomplish that.

To put that in layman's terms:
Q: How do you make a symlink on Android such that swapping out a 64GB
sd card with a 128GB sdcard won't affect where that Android editor
"thinks" it stored its files (when the sdcard Volume Name/Label is
suddenly completely different)?
A: ?

If you can propose HOW I can test that out, I'd be glad to test it.
a. Linux isn't the question (ln -s [target] [symlink])
b. Neither is Windows (mklink [[/D] | [/H] | [/J]] <Link> <Target>)
c. The problem is non-root Android symlinks are problematic, are they not?

(I'm not sure this is "clever" or "helpful" (as your suggestion is,
according to your subject), but it appears much more sensible to me.
Isn't that possible on Windows and Android to preserve portability?)

I like the idea of a non-root Android symlink, and, rest assured, that's actually the very first idea that popped into my head (as it did for yours
and for Carlos' apparently).

So we all leaning toward what may be a rather profound global solution.
But the problem with creating symlinks on non-rooted Android is well known.

Android apps can usually create symlinks within their own data directories,
so if you know of such Android file editors, please let us all know.

But symlinking inside of every Android file editor isn't really elegant.
For a more global elegant solution, certainly we could strive to use "the
ln -s command in the adb shell, but that's fraught with difficulties due to Android file system restrictions, especially in areas like /system or /data which have strict permissions preventing symlinks in protected areas.

[*] I, and the OS, should actually have an interest to know whether
there's another (or new) device in the system.

Ah. You bring up an excellent (and rather astute) intelligent point as to
WHY the sd card happens to have three different identifiers, by default!

Bearing in mind that there are 3 identifiers of merit in this discussion
1. Volume ID (CID) is assigned by the OEM & is not changeable by the user
2. Volume Serial Number is uniquely created during the formatting process
3. Volume Name (aka Volume Label) is *intended* to be changed by the user

Certainly, it's well known that the Serial Number is the primary identifier that the operating system is "expected" to know about & take into account.

And just as certainly, the whole point of the Volume Name (aka Volume
Label) is to perform the elegant task that was initially suggested in this thread.

Note you can change the Volume Serial Number, but I'm not aware of an
Android editor that makes use of that Volume Serial Number, so why do it?

[**] A quick browse of the Net shows that you could [on Windows] also
just simply change that label by context menu 'properties'.

Let's be abundantly clear that we're not changing things simply for the
sake of changing them - but we're planning ahead - years ahead in fact -
for a migration so that Android editors can find their files which are
stored on sd cards when (years from now) you double your sd card size.

In summary, the only "thing" we want to change, is the thing that matters.
a. Not the Volume ID (aka CID), which is used at the hardware level
b. Not the Serial Number, which is sort of a "partition" identifier
c. But the Volume Name, which is used at the file-explorer & editor level

Having stated the elegance of changing the only thing that matters to the Android editors (which need to find files on the sd card), I agree if you
can figure out how to symlink on non-root Android, you'd have all my
respect (as that's an elegant task that I haven't yet been able to do!).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 10:15:04 +0000, Andy Burns wrote :

Take into account, my first Android device (Nexus1) had a microSD slot, which it certainly needed due to only having 512MB of onboard flash and 512MB of RAM, so plenty of swapfile and moving parts of the system to SD
... but no phone I've owned since then has had a card slot.

Hi Andy,

You bring up a good point that people have to live with their decisions.
With that in mind... as you're quite well aware...

We've had the lack of sd discussion so many times on both the Android & on (paradoxically) the Apple newsgroups, that I'm sure you realize the last
time we checked, the vast majority of Android phones have an sd card slot.

With that observation that, last I had checked most Androids still have an
sd slot in mind...

And... without rehashing the glaringly obvious fact that it was your choice
to NOT have an sd card slot...

Q: How do *you* double your portable storage when you need to, Andy?
A: ?

You can't, right?
For about $10, I (we) can.

Seamlessly. As long as I (rather elegantly) plan years ahead, that is.
<https://i.postimg.cc/bNGTzR6q/sdcard1.jpg>

I can triple & quadruple that portable storage, any time I feel like it.
You can't. Right? <https://i.postimg.cc/j2VCtRPX/sdcard02.jpg>

For as many phones as I want to do it for, right?

(Note: I have 3 free Samsung Galaxy A32-5Gs in my household right now.) <https://i.postimg.cc/Xq5SpS4D/tmopromo02.jpg>

So, for about $30, I can double the memory of every Android in the house!
You can't do *any* of that, right?

Personally, unless I was made out of pure money, I wouldn't touch an
Android phone that didn't have both the sd card slot & the aux jack.

Please see the sig for the caveats.
--
Note: We all know that Apple & Google want to push people toward storing
their editing files being stored on 'someone else's computer', but this is
not "portable storage" in the sense that I'm using the term.

The way I'm using "Portable Storage" is in the examples I already provided, where I've replaced (twice now!) the same model phone with a free
replacement under warranty where the sd card was swapped out and the
editors on Android didn't even realize they were on a different phone.

In addition, as Andy is also well aware, I even tested *doubling* the
storage size on the third phone, and the Android editors didn't even
flinch.

That's the huge significance of "portable" in the term "portable storage".
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 18:45:25 -0000 (UTC), Marion wrote :

<https://i.postimg.cc/Xq5SpS4D/tmopromo02.jpg>

So, for about $30, I can double the memory of every Android in the house!
You can't do *any* of that, right?

In all fairness to Andy, whom I know to be an intelligent and thoughtful person, I belatedly realize that Andy seems to think the sd card has only
one purpose - which is to *extend* the memory of the Android phone.

Which is a worthless concept nowadays... I agree.

I partly helped Andy be confused because I interchangably used the word "storage" and "memory" where that's what threw Andy off the main track.

Suffice to say that nobody (well, almost nobody) needs to "extend" the
memory of their Android phone nowadays ... even I don't need to do that and
all my phones are always free (just like all my Amazon purchases are free).
<https://amazon.com/vine/about>

What I'm talking about here, is NOT extending the memory but DOUBLING the storage (tripling the storage, quadrupling the storage, whatever).

As sdcards get cheaper, I pop a new triple-sized sdcard into my phone, and Voila! Instantly all my editors have TRIPLE the storage to store files in!

That's what I mean by "portable storage".

Given that important clarification that it's not "memory" I'm doubling, but portable storage that I'm doubling, I can ask again Andy this question:

Q: How do *you* double your portable storage when you need to, Andy?
A: ?

You can't, right?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 14:55:50 +0100, Carlos E.R. wrote :

SD card terminology confuses people because there are at least 3 terms:
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

You can change them in Linux.

Going from memory, one of them you change in the partitioner (fdisk).
This one was crucial with Windows 7 because M$ would use it to detect machine change or pirated copy.

All these changes can be done without formatting and losing the content.

Hi Carlos,

You bring up a good point that I did a bad job of explaining the problem
set (& hence, in your appreciation of the sheer elegance of the solution).

Mea culpa.
I apologize.

It's (almost certainly) my fault that you & Andy (& perhaps many others)
are (apparently) confused about sd card use & terminology; specifically,
the reason why one would benefit by changing the Volume Name (aka Label).

For sdcards, portable memory is not the same thing as portable storage.

Hence, from this moment, I'll STOP using the word "memory" in terms of sd
card terminology as I will use the more apt term of "storage" for sd cards.

That is, portable memory is not at all the same thing as portable storage.
And it's MY FAULT for muddying up the waters on that distinction.

Hopefully my prior response to Andy will clear up that I am only discussing here how to *seamlessly* double (or triple or quadruple or whatever) your Android portable mem... ah, er, um "storage" (for only about ten bucks).

Note: I get all my sd cards for free off of Amazon Vine; but most people
have to pay for their stuff on Amazon, so I'm assuming it costs them $10.

Please be acutely aware of the fact that the elegance isn't in doubling or tripling your storage. The elegance is in the word "*seamless*".

The editor has no clue that you just swapped out the sd card to a new one!
But, of course, the editor has to prior be aware of storage on the sd card.

That is, all your modern editors (which is why I stressed the word "modern"
in the original post) "should" be able to find their files on your portable memory sd card where, if you use this insightful trick, they won't even
know that you just doubled the sd storage space that the editors have
access to.

I feel sorry for people who don't have Android phones with sd card slots. Because if they want to double their portable storage, they can't.

It's impossible (without adding hardware that sticks out of the phone).

Hence, I already explained to Andy (where lurkers can benefit) that there
is no way (that I know of) for *him* to double his portable memory (for ten bucks anyway). But most Android phones still have sd card slots (AFAIK).

Now that we have the concept of "portable storage" clarified, let's look at what people are confused about in the three typical sd card identifiers.

Why would we want to control the value of *any* of these?
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

Ignoring that the Volume ID is not changeable by the user, and hence has no value to us in controlling how Android editors find their sd card files...

To your point of being easily able to change the other two using Windows
(or Linux), why would you want to change the Volume Serial Number?

Is there some value that you see in doing that which I don't yet comprehend which makes doing so of value in terms of controlling Android file editors?

Remember, the whole point is that a simple elegant trick on Windows (or
Linux) done years ahead of time, makes it seamless to double (or triple)
the sd portable storage that is available to your modern Android editors.

If a symlink will work on non-root Android, then that's the Holy Grail.
CHANGE FROM: /storage/sdcard1/ABCD-ABCD/{my editor's folders & files)

CHANGE TO: /storage/sdcard1/symlink/{my editor's folders & files)
or perhaps...
CHANGE TO: /storage/symlink/{my editor's folders & files)

I have never been able to accomplish that illustrious glorious task.
Can you?
How?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-01 20:16, Marion wrote:

On Sat, 1 Feb 2025 14:55:50 +0100, Carlos E.R. wrote :

SD card terminology confuses people because there are at least 3 terms:
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

You can change them in Linux.

Going from memory, one of them you change in the partitioner (fdisk).
This one was crucial with Windows 7 because M$ would use it to detect
machine change or pirated copy.

All these changes can be done without formatting and losing the content.

Hi Carlos,

You bring up a good point that I did a bad job of explaining the problem
set (& hence, in your appreciation of the sheer elegance of the solution).

Mea culpa.
I apologize.

It's (almost certainly) my fault that you & Andy (& perhaps many others)
are (apparently) confused about sd card use & terminology; specifically,
the reason why one would benefit by changing the Volume Name (aka Label).

For sdcards, portable memory is not the same thing as portable storage.

Hence, from this moment, I'll STOP using the word "memory" in terms of sd card terminology as I will use the more apt term of "storage" for sd cards.

That is, portable memory is not at all the same thing as portable storage. And it's MY FAULT for muddying up the waters on that distinction.

Hopefully my prior response to Andy will clear up that I am only discussing here how to *seamlessly* double (or triple or quadruple or whatever) your Android portable mem... ah, er, um "storage" (for only about ten bucks).

Note: I get all my sd cards for free off of Amazon Vine; but most people
have to pay for their stuff on Amazon, so I'm assuming it costs them $10.

Please be acutely aware of the fact that the elegance isn't in doubling or tripling your storage. The elegance is in the word "*seamless*".

The editor has no clue that you just swapped out the sd card to a new one! But, of course, the editor has to prior be aware of storage on the sd card.

I don't use editors on phone nor tablet.

And, my editor by default inserts photos inside the document file. I can
link to external photos, but then, as I use Linux, I would use relative
paths or symlinks.

Also I *never* edit a file residing in flash storage. I edit in main
storage in the computer, then copy the result over to flash media if needed.

That is, all your modern editors (which is why I stressed the word "modern" in the original post) "should" be able to find their files on your portable memory sd card where, if you use this insightful trick, they won't even
know that you just doubled the sd storage space that the editors have
access to.

I feel sorry for people who don't have Android phones with sd card slots. Because if they want to double their portable storage, they can't.

I haven't had that need in over a decade.

It's impossible (without adding hardware that sticks out of the phone).

Hence, I already explained to Andy (where lurkers can benefit) that there
is no way (that I know of) for *him* to double his portable memory (for ten bucks anyway). But most Android phones still have sd card slots (AFAIK).

Now that we have the concept of "portable storage" clarified, let's look at what people are confused about in the three typical sd card identifiers.

Why would we want to control the value of *any* of these?
1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

Ignoring that the Volume ID is not changeable by the user, and hence has no value to us in controlling how Android editors find their sd card files...
To your point of being easily able to change the other two using Windows
(or Linux), why would you want to change the Volume Serial Number?
Is there some value that you see in doing that which I don't yet comprehend which makes doing so of value in terms of controlling Android file editors?

Fooling Windows into thinking you have not changed computer. Windows
used that value for finding pirated copies.

Also you need to write those values when cloning hard disks (or flash
media).

Storage cards are formatted the same as a hard disk. They contain
partition tables, and all the identifiers of a hard disk and the
partitions inside. And all the tools Windows or Linux have available for
hard disks will work on them.

Remember, the whole point is that a simple elegant trick on Windows (or Linux) done years ahead of time, makes it seamless to double (or triple)
the sd portable storage that is available to your modern Android editors.

If a symlink will work on non-root Android, then that's the Holy Grail. CHANGE FROM: /storage/sdcard1/ABCD-ABCD/{my editor's folders & files)

CHANGE TO: /storage/sdcard1/symlink/{my editor's folders & files)
or perhaps... CHANGE TO: /storage/symlink/{my editor's folders & files)

I have never been able to accomplish that illustrious glorious task.
Can you?
How?

--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-01 16:34, Janis Papanagnou wrote:

[*] I, and the OS, should actually have an interest to know whether
there's another (or new) device in the system.

Indeed.

Long ago, I swapped a floppy but the software (DOS+TP) thought it was
still the same floppy, and wrote the FAT and directory to the second
floppy of the first floppy, resulting in corruption of the computer work
I had to present my teachers. I couldn't blame the cat, but...
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 06:03:49 -0000 (UTC), Marion wrote:

2. Volume Serial Number:

Format: A 32-bit number, usually displayed as 8 hexadecimal
characters
(e.g., A1B2C3D4).
How it's assigned: Generated when the SD card is formatted. It can
change if you reformat the card.

This is a function of the filesystem format. For example, Linux
filesystems commonly use full-length UUIDs for this purpose.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 14:55:50 +0100, Carlos E.R. wrote:

1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

You can change them in Linux.

Not the first one, though, if thatrCOs wired into the hardware.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote:

Also I *never* edit a file residing in flash storage.

Does your system not have an SSD?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote :

The editor has no clue that you just swapped out the sd card to a new one! >> But, of course, the editor has to prior be aware of storage on the sd card.

I don't use editors on phone nor tablet.

Hi Carlos,

If you don't ever use editors on a mobile device, then that's unusual.
Most people experience using editors on a mobile device, even if you don't.

But I find it hard to believe you don't use editors on a mobile device.

You don't use offline maps for example? Really? Seriously?
How do you navigate using your phone when there is no Internet signal?

Offline map editors are just one type of editor on an Android phone.
I, for one, do a lot of editing on an Android phone.

Another editor is Keepass2Android. There are plenty of Android editors.
Most (if not almost all) my private data is stored on the sd card.

And, my editor by default inserts photos inside the document file.

Photo editors are a different breed of app when it comes to "finding" their files. I'm not sure *how* media is handled differently than, oh, say, text files such as GPX files or PDF files or whatever - but there is some
"magic" on a phone that seems to find all media, no matter where it is.

So media (such as images & video) I think is a special case in this regard.

That is, even if you changed the volume name (aka volume label) of your sd card, the image & video editors still seem to *find* the sd card files.

If those on this newsgroup can edify us as to why that magic only works for media files, and not for, oh, say, text files (such as GPX files), please elucidate why other formats (such as PDF, gpx, kml, etc.) aren't easily
found.

I can
link to external photos, but then, as I use Linux, I would use relative paths or symlinks.

I love your suggestion of symlinks, but as I painstakingly explained,
nobody yet has proposed a way to do it that I know of, for Android.

If you can get symlinks to work on the sdcard for Android, you'd be a far
more intelligent man than I am, so I'll patiently await how you do it.

Also I *never* edit a file residing in flash storage. I edit in main
storage in the computer, then copy the result over to flash media if needed.

Hmm... how do you edit GPX or KML files?

Do you copy them from the sd storage to main storage just to edit them?
Why?

I feel sorry for people who don't have Android phones with sd card slots.
Because if they want to double their portable storage, they can't.

I haven't had that need in over a decade.

Hmm. If you have never done it, and if all your suggestions can't possibly work, why are you making those suggestions which have no hope of working?

Ignoring that the Volume ID is not changeable by the user, and hence has no >> value to us in controlling how Android editors find their sd card files... >> To your point of being easily able to change the other two using Windows
(or Linux), why would you want to change the Volume Serial Number?
Is there some value that you see in doing that which I don't yet comprehend >> which makes doing so of value in terms of controlling Android file editors?

Fooling Windows into thinking you have not changed computer. Windows
used that value for finding pirated copies.

Hmm... you seem to be completely unaware of what the problem set is.
The problem set is fooling Android. Specifically editors. By using Windows.

Also you need to write those values when cloning hard disks (or flash media).

Huh? Nobody is suggesting cloning. This solution only requires copying.

Cloning, e.g., using dd, is a completely different issue altogether:
sudo dd if=/dev/source_disk of=/dev/destination_disk bs=4M status=progress

Storage cards are formatted the same as a hard disk. They contain
partition tables, and all the identifiers of a hard disk and the
partitions inside. And all the tools Windows or Linux have available for hard disks will work on them.

Again, I love your suggestion of symlinks, which is the first thing anyone would think of, but if you can get symlinks to work on non-rooted Android
for the sdcard, then you're a far more intelligent man than I am.

Please let us know how you accomplished tasks which you keep suggesting.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 04:16:33 -0000 (UTC), Marion wrote :

So media (such as images & video) I think is a special case in this regard.

To further add value...

Given editing of multimedia files is a special case... and since this is
all about editors finding their files when the storage is doubled, we
should note that editing on phones is often far better than on desktops.

Why, I don't know - but free cartoonify editors, in particular, seem to be vastly more powerful on phones than they are on any desktop I've ever used.

Given media editors are sometimes far more advanced on mobile devices, it behooves all of us to better understand *how* phones tread multimedia files *differently* than all other file types (as far as I'm aware anyway).

That is, even if I doubled my portable storage without bothering to match
the old sdcard volume name (aka volume label), the editing apps *still*
seem to find the special class of files known as multimedia files.

That's great but why does Android treat only multimedia that way?
Why not scan for all file types?

Why does Android have a special system to scan *only* for multimedia files, such that doubling your sdcard portable memory causes no ill effects.

Editors can still *find* your multimedia files even after doubling storage!

I'm well aware of the trick to have the operating system *not* find them:
/storage/0000-0001/0001/.nomedia
But why does Android treat *only* media differently (using the media
Scanner Service)? What about other files that we often edit?
<com.android.providers.media>

For example, if we double the portable storage, the media scanner system service is automatically triggered to scan the new portable storage for
media files (images, audio, and video). When it finds a new "media" file (e.g., a .jpg, .png, .mp3, or .mp4, etc.), the media scanner extracts its concomitant metadata (like artist, album, title, date, resolution, etc.)
and adds this information to the Android MediaStore SQLite database.
/data/data/com.android.providers.media/databases/
Specifically, in a table containing a separate section each for
MediaStore.Images
MediaStore.Video
MediaStore.Audio

In summary, we probably need to clarify that there are two kinds of
editors, only one of which is severely impacted when we double storage.
a. Editors have no problem finding impacted media files
b. But editors can't find all other impacted file types

Unless you know the trick. :)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 05:40:17 -0000 (UTC), Marion wrote:

... free cartoonify editors, in particular, seem to
be vastly more powerful on phones than they are on any desktop I've ever used.

Anything as powerful as this <https://www.youtube.com/watch?v=hzqD4xcbEuE>?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-02 04:21, Lawrence D'Oliveiro wrote:

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote:

Also I *never* edit a file residing in flash storage.

Does your system not have an SSD?

Mmm. Certainly, but it is another kind, designed for intensive use.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-02 04:21, Lawrence D'Oliveiro wrote:

On Sat, 1 Feb 2025 14:55:50 +0100, Carlos E.R. wrote:

1. Volume ID (CID)
2. Volume Serial Number
3. Volume Name (aka Volume Label)

You can change them in Linux.

Not the first one, though, if thatrCOs wired into the hardware.

I would need to know the name in Linux parlance to be sure. I have not
noticed an identifier tied to the hardware, except model and serial
number in hard disks. I'm unsure flash sticks have this.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-02 05:16, Marion wrote:

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote :

The editor has no clue that you just swapped out the sd card to a new
one!
But, of course, the editor has to prior be aware of storage on the sd
card.

I don't use editors on phone nor tablet.

Hi Carlos,

If you don't ever use editors on a mobile device, then that's unusual.
Most people experience using editors on a mobile device, even if you don't.

But I find it hard to believe you don't use editors on a mobile device.

You don't use offline maps for example? Really? Seriously?
How do you navigate using your phone when there is no Internet signal?

Till today I had no idea you were talking of map editors. I was thinking
text editors.

No, I do not use map editors on my phone, either. I use map apps that
view the map, not edit them.

Offline map editors are just one type of editor on an Android phone.
I, for one, do a lot of editing on an Android phone.

Another editor is Keepass2Android. There are plenty of Android editors.
Most (if not almost all) my private data is stored on the sd card.

I don't "edit" my password file on the phone.

And, my editor by default inserts photos inside the document file.

Photo editors are a different breed of app when it comes to "finding" their files. I'm not sure *how* media is handled differently than, oh, say, text files such as GPX files or PDF files or whatever - but there is some
"magic" on a phone that seems to find all media, no matter where it is.

So media (such as images & video) I think is a special case in this regard.

That is, even if you changed the volume name (aka volume label) of your sd card, the image & video editors still seem to *find* the sd card files.

If those on this newsgroup can edify us as to why that magic only works for media files, and not for, oh, say, text files (such as GPX files), please elucidate why other formats (such as PDF, gpx, kml, etc.) aren't easily found.

Because "editor" to me is a text editor, and I was thinking of the one I
use, Libre Office Writer. Ok, a word processor. If I have to edit pure
plain text files they are just a few kilobytes in size.

I can link to external photos, but then, as I use Linux, I would use
relative paths or symlinks.

I love your suggestion of symlinks, but as I painstakingly explained,
nobody yet has proposed a way to do it that I know of, for Android.

Your question is posted to the editors group, and to the windows group,
so I don't have to limit my thinking to Android.

If you can get symlinks to work on the sdcard for Android, you'd be a far more intelligent man than I am, so I'll patiently await how you do it.

Also I *never* edit a file residing in flash storage. I edit in main
storage in the computer, then copy the result over to flash media if
needed.

Hmm... how do you edit GPX or KML files?

I don't.

I thought you were talking of text files.

Do you copy them from the sd storage to main storage just to edit them?
Why?

Because the wear in flash cards is limited, and using an editor in such
media stresses them.

I feel sorry for people who don't have Android phones with sd card
slots.
Because if they want to double their portable storage, they can't.

I haven't had that need in over a decade.

Hmm. If you have never done it, and if all your suggestions can't possibly work, why are you making those suggestions which have no hope of working?

Arlen, you have changed the goalposts. You never said you were not
talking of text editors till today.

Ignoring that the Volume ID is not changeable by the user, and hence
has no
value to us in controlling how Android editors find their sd card
files...
To your point of being easily able to change the other two using Windows >>> (or Linux), why would you want to change the Volume Serial Number?
Is there some value that you see in doing that which I don't yet
comprehend
which makes doing so of value in terms of controlling Android file
editors?

Fooling Windows into thinking you have not changed computer. Windows
used that value for finding pirated copies.

Hmm... you seem to be completely unaware of what the problem set is.
The problem set is fooling Android. Specifically editors. By using Windows.

I'm sure that Windows has tools to change those values without
formatting the media, you just have to find them. I am a Linux guy, so I
know how to do that in Linux.

Also you need to write those values when cloning hard disks (or flash
media).

Huh? Nobody is suggesting cloning. This solution only requires copying.

No, Arlen, I'm just giving an example of why the need to edit that
value. One that I have needed to do in the past. I'm not suggesting you
clone anything.

Cloning, e.g., using dd, is a completely different issue altogether:
sudo dd if=/dev/source_disk of=/dev/destination_disk bs=4M status=progress

Storage cards are formatted the same as a hard disk. They contain
partition tables, and all the identifiers of a hard disk and the
partitions inside. And all the tools Windows or Linux have available
for hard disks will work on them.

Again, I love your suggestion of symlinks, which is the first thing anyone would think of, but if you can get symlinks to work on non-rooted Android
for the sdcard, then you're a far more intelligent man than I am.

Please let us know how you accomplished tasks which you keep suggesting.

You posted in three groups, the answers do not have to be limited to one operating system. I said I never "edit" on Android. Meaning Libre Office Writer, or Microsoft Word. You did not say till today that you were
editing maps in the woods without internet. And no, I never felt the
need to edit maps on the phone. I just view them with an app, typically OSMand+.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 01.02.2025 17:29, Kenny McCormack wrote:

In article <vnletd$5l96$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

(I probably shouldn't engage in this thread - and not only because it
got aggressive recently - because it seems (partly?) a Windows issue,
given the mention of 'C:', 'D:' and such crap later in this thread;
but I'm curious...)

Calling drive letters "crap" isn't "aggressive" ?

I wouldn't think so, but maybe we have a different view on that. What I
meant and was addressing was the _ad hominem_ aggressivity. (It wouldn't
have occurred to me that calling a technical mis-design "crap" would be considered aggressive.) I think that personal "Die fucking troll, Die."
[from "Quincy the fifth"] is something vastly different than "Feature
C: D: is crap."

Anyway, given that this is a cross-posted thread, it would be useful to
know from which group you are reading/responding. I often give this info myself when responding to cross-posts.

My guess it that, like me, you are reading in comp.editors. The point of this observation is that this thread (whatever it does eventually turn out
to really be about) is really more of an Android/Windows thing, and is only tangentially related to editors. If you're coming from a primarily Unix (aka, Linux) background, a lot of it will look weird. I don't understand
it myself, but I am inferring (just from reading this thread) that there
are weirdnesses in both Android and Windows that give rise to the issues
that Arlen is trying to address.

Neither you nor I are familiar with these weirdnesses and problems, because we both come primarily from Unix/Linux backgrounds - where such things
simply don't exist.

Well, I worked in the past also in DOS and Windows environments. And I
seem to recall that there were some sorts/variant of "links" available
(but I might be misremembering). And Android is a Linux (Unix) based OS
so I'd expect that such primitive and basic mechanisms are nor removed
from this OS. But I don't know; so if it's not applicable readers may
just dismiss my hint.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 01.02.2025 19:10, Marion wrote:

[...]

[symbolic links]

This was brought up prior, I think by Carlos if I remember correctly,

(I may have missed that. - Sorry, Carlos!)

where
I restrained myself from incredulously asking HOW he proposed to do that symlinking on Android such that the all-important Android file editors
would still recognize a path that has completely changed out from under
them.

You again stirred my curiosity - since I don't know about the Android
and its file-editors peculiarities... - How does Android recognize the
path with the (arbitrary) "A1B1-C1D1" and "A2B2-C2D2" path components
but not a generic (a fixed) one?

To be clear, I'm absolutely and emphatically NOT saying it can't be
done; nor am I even intimating that it's not a great idea - I'm only
asking, eyes
wide open with intrigue, HOW you (and Carlos) would accomplish that.

I'm lacking Android competences so I cannot provide more than a hint.
Sorry. (If it doesn't work for reasons beyond my expertise please just
ignore my post.) I would have thought there's (as so often) some menu
entry or (either system- or editor-specific) properties file to change
or define that.

Janis

[...]

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-02 15:24, Janis Papanagnou wrote:

On 01.02.2025 17:29, Kenny McCormack wrote:

In article <vnletd$5l96$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

(I probably shouldn't engage in this thread - and not only because it
got aggressive recently - because it seems (partly?) a Windows issue,
given the mention of 'C:', 'D:' and such crap later in this thread;
but I'm curious...)

Calling drive letters "crap" isn't "aggressive" ?

I wouldn't think so, but maybe we have a different view on that. What I
meant and was addressing was the _ad hominem_ aggressivity. (It wouldn't
have occurred to me that calling a technical mis-design "crap" would be considered aggressive.)

Some people do. I was called to attention and maybe banned from a Linux
forum for such an opinion. I assume because developers and packagers are
part of the community, and calling a software crap is insulting the
developer who might be reading and is working gratis.

I think that personal "Die fucking troll, Die."
[from "Quincy the fifth"] is something vastly different than "Feature
C: D: is crap."

Anyway, given that this is a cross-posted thread, it would be useful to
know from which group you are reading/responding. I often give this info
myself when responding to cross-posts.

My guess it that, like me, you are reading in comp.editors. The point of
this observation is that this thread (whatever it does eventually turn out >> to really be about) is really more of an Android/Windows thing, and is only >> tangentially related to editors. If you're coming from a primarily Unix
(aka, Linux) background, a lot of it will look weird. I don't understand
it myself, but I am inferring (just from reading this thread) that there
are weirdnesses in both Android and Windows that give rise to the issues
that Arlen is trying to address.

Neither you nor I are familiar with these weirdnesses and problems, because >> we both come primarily from Unix/Linux backgrounds - where such things
simply don't exist.

Well, I worked in the past also in DOS and Windows environments. And I
seem to recall that there were some sorts/variant of "links" available
(but I might be misremembering). And Android is a Linux (Unix) based OS
so I'd expect that such primitive and basic mechanisms are nor removed
from this OS. But I don't know; so if it's not applicable readers may
just dismiss my hint.

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <vnnv7i$nmrk$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

Calling drive letters "crap" isn't "aggressive" ?

I wouldn't think so, but maybe we have a different view on that. What I
meant and was addressing was the _ad hominem_ aggressivity. (It wouldn't
have occurred to me that calling a technical mis-design "crap" would be >considered aggressive.)

Maybe it is a language barrier (*), but, yes, there is a strong feeling nowadays that criticizing a technology *is* criticizing the people who use
that technology (and like it). And they get defensive about it. When you criticize, say, DOS/Windows drive letters, all those people who like that
sort of thing get all fee-fee-hurt and react accordingly. Thus, on some forums, you are not allowed to criticize any technology.

(*) English not being your first language (not that there is anything wrong with that...)

I think that personal "Die fucking troll, Die."
[from "Quincy the fifth"] is something vastly different than "Feature
C: D: is crap."

Oh, that. That's just the ravings of a lunatic. No one pays it any
attention whatsoever.

I thought you were referring to my first post on this thread, commenting on
the ravings of our resident lunatic (Arlen). That could be seen as "aggressive". That post is what set our resident lunatic on fire in the
first place (Don't know if you've noticed, but Q5 has been posting that
crap all over Usenet, not just here).

Well, I worked in the past also in DOS and Windows environments.

I would imagine so. But Android is actually more different from Linux
than Windows is from Unix/Linux.

And I seem to recall that there were some sorts/variant of "links"
available (but I might be misremembering).

Yeah, true, but not particular relevant to this discussion.

Note that symlinks do work under Android (I do it all the time), but Arlen
is too busy discovering his navel to realize that.

And Android is a Linux (Unix) based OS
so I'd expect that such primitive and basic mechanisms are nor removed
from this OS. But I don't know; so if it's not applicable readers may
just dismiss my hint.

Yes, Android is Linux based, but it is enough different that I consider it
a separate animal. Essentially, everything that isn't absolutely necessary
is disabled, so it is very hard to work in. It is kind of like Linux with
both hands tied behind your back. You have to hit the keyboard (i.e.,
screen) with your nose.
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RepInsults
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 02.02.2025 15:50, Carlos E.R. wrote:

On 2025-02-02 15:24, Janis Papanagnou wrote:

On 01.02.2025 17:29, Kenny McCormack wrote:

In article <vnletd$5l96$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

(I probably shouldn't engage in this thread - and not only because it
got aggressive recently - because it seems (partly?) a Windows issue,
given the mention of 'C:', 'D:' and such crap later in this thread;
but I'm curious...)

Calling drive letters "crap" isn't "aggressive" ?

I wouldn't think so, but maybe we have a different view on that. What I
meant and was addressing was the _ad hominem_ aggressivity. (It wouldn't
have occurred to me that calling a technical mis-design "crap" would be
considered aggressive.)

That is understandable. - Though the guy who invented the "device
letters" concept (40+ years ago!) probably doesn't mind (anymore)
even if he'd take that (unjustified) as _personal_ offense, which
it obviously isn't.

Some people do. I was called to attention and maybe banned from a Linux
forum for such an opinion. I assume because developers and packagers are
part of the community, and calling a software crap is insulting the
developer who might be reading and is working gratis.

Valuing a complete software package is again another thing. (Yet,
still not a personal thing.)

[...]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

(Sorry, I misplaced my answer to the quote wrongly above the text
in my previous post. - Hope the intention was clear anyway.)

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 02.02.2025 15:50, Carlos E.R. wrote:

[...]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

To be clear, Android's native filesystem is not FAT (but ext4), but if
you use a (Micro)SD-card in an Android device (which is partly the
subject of this ... ahem ... 'thread'), then the filesystem on that card
is FAT (assuming it's not used as an extension of Internal Storage
('disk' space)).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <vnoa2f.qag.1@ID-201911.user.individual.net>,
Frank Slootweg <this@ddress.is.invalid> wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 02.02.2025 15:50, Carlos E.R. wrote:

[...]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

To be clear, Android's native filesystem is not FAT (but ext4), but if
you use a (Micro)SD-card in an Android device (which is partly the
subject of this ... ahem ... 'thread'), then the filesystem on that card
is FAT (assuming it's not used as an extension of Internal Storage
('disk' space)).

Yes, all true. Interestingly, at least the one time I tested this, when I formatted an SD card to ext4, then inserted it into a phone, it did not recognize it. Odd, because obviously, it *can* recognized ext4
filesystems. But it only seems to be able to do FAT on the SD card.
--
"Only a genius could lose a billion dollars running a casino."
"You know what they say: the house always loses."
"When life gives you lemons, don't pay taxes."
"Grab 'em by the p***y!"
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 06:05:26 -0000 (UTC), Lawrence D'Oliveiro wrote :

... free cartoonify editors, in particular, seem to
be vastly more powerful on phones than they are on any desktop I've ever
used.

Anything as powerful as this <https://www.youtube.com/watch?v=hzqD4xcbEuE>?

Given this is an editing group, that heartfelt value added is useful. Especially as I always click on any link people kindly go to the trouble of supplying (so that I learn better what it is they are trying to teach me).

Thank you for being purposefully value added helpful, as face "cartoonify" capabilities, in my humble opinion, based on my experience, suck on Windows versus Android. Notice I added "face" as that's how I use them (e.g., to
take someone's image and cartoonify it for them for humor or so that they
can use it as a privacy-aware avatar with their social media monikers).

Interesting that you mentioned the blender app as I have strived to install (and at least briefly test) every single free "editing" app ever posted to
the Windows-10 newsgroup over the years; so certainly I already had Blender installed - but - it's in my 3D folder. See my ad hoc %EDITOR% screenshot.
<https://i.postimg.cc/pdC7R5Jw/blender01.jpg>

From the time stamps, it looks like I first installed Blender on my desktop
PC in October of 2018, and I last updated Blender in July of 2022.

As I recall, Blender was extremely powerful; but I was looking at it for 3D
CAD purposes (I think so that I could calculate oddly-shaped pool volumes).

As a Windows-editor-related aside, I've tested all the free suggested cartoonify apps on Windows, as shown by this ad hoc %EDITOR% screenshot.
<https://i.postimg.cc/NFgH18Gp/photo-editor01.jpg>

Most of those %EDITORS% are to edit a screenshot (i.e., arrows, boxes &
text); but some are for depth-of-field overlays or oil paintings or to
remove blemishes, or some other rather specialized non-AI activity.

A good AI activity of free cartoonifying, I haven't yet found on Windows. Looking at the link on Android mirrored over onto Windows, I see this:
<https://i.postimg.cc/9Qvg3j53/blender-grease01.jpg>
<https://i.postimg.cc/tJmRpzHM/blender-grease02.jpg>
<https://i.postimg.cc/Zq52ZzVV/blender-grease03.jpg>
<https://i.postimg.cc/Kz8yjgQS/blender-grease04.jpg>
<https://i.postimg.cc/9FpKRfRc/blender-grease05.jpg>
<https://i.postimg.cc/ydb2Npkc/blender-grease06.jpg>

OMG! That's beautiful. Very awe-inspiringly beautiful. But, perhaps a lot
of knowledge is required, whereas with the phone-based AI, no knowledge is necessary (but, of course, you only get the AI-generated choices also).

By way of stark contrast, the results from Android AI-based cartoonify
programs are (essentially) almost uncontrollable - but they too are nice.

To always add value, my favorite Android cartoonify editors, are these:
*PhotoRoom Studio Photo Editor* by Artizans of Photo Video BG Editor App
Free, with ads, rated 4.7, 10M+ installs, requires GSF
<https://play.google.com/store/apps/details?id=com.photoroom.app>
[PhotoRoom can be screenshotted.]
[PhotoRoom is ok with adb shell screencap -p /sdcard/Download/screenshot.png]
[PhotoRoom is good for transparizing the background away magic wand style.]
[PhotoRoom saves the results with a watermark easily cropped.]

*Photo Lab* Picture Editor & Art, by Linerock Investments LTD
Free, with ads, rated 4.6, 100M+ installs, requires GSF
<https://play.google.com/store/apps/details?id=vsin.t16_funny_photo>

*ToonMe* cartoons from photos, by Linerock Investments LTD
Free, with ads, rated 4.4, 50M+ installs, requires GSF
<https://play.google.com/store/apps/details?id=com.vicman.toonmeapp>

*Voila* AI Artist Cartoon Photo by Wemagine.AI
free, +ads (really obnoxious), requires gsf, rated 4.6, 10M+ installs
<https://play.google.com/store/apps/details?id=com.wemagineai.voila>

In their own way, the cartoonify AI on Android is good - but it pales in comparison to that inspiring video of what the Blender grease pencil does.
<https://www.youtube.com/watch?v=hzqD4xcbEuE>

Thanks for helping the Windows & %EDITORS% people by suggesting Blender!

I'm going to have to find a tutorial that shows the *easiest* way to
cartoonify something very simple - such as a closeup face portrait.
--
Every post should add value for the vast majority of people reading it.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Woo hoo! The solution has been greatly improved!

It's important to note that Carlos kindly further improved this clever
trick, turning what was merely ingenious into brilliant in simplicity.

See below for details - where Carlos' solution supersedes that of mine!

Many thanks to Carlos (and others) for adding value in this thread!

On Sun, 2 Feb 2025 23:20:45 +0100, Carlos E.R. wrote :

-----< cut here for post that went only to the Android ng >-----
On Sun, 2 Feb 2025 23:20:45 +0100, Carlos E.R. wrote :

Ok, now that I understand what type of editor you are talking about and
the scenario,

Well, that's only one type of editor, but it's an editor that most of us
can agree that if we had an sdcard, that we'd want to store the (admittedly huge) map data on that sdcard, which then needs to be edited at times.

I can agree that changing the label of the card is the thing to do.

I think most people perhaps don't understand the genius of my advice
because they, themselves, never bothered to try to overcome problems.

So they've never experienced a seamless non-cloud phone-to-phone upgrade.
I have.

It is a particular scenario.

I agree that about many Android phones sold today don't have a portable
storage slot (or it does double duty for the SIM card perhaps); but last we checked, most Androids still came with the portable storage sdcard slot.

Given that is coupled with the fact that {OSMAnd~/OSMAnd+/OSMAnd} is a
common offline map application, people have to store its data somewhere.

It either takes up a lot of space on the sdcard0 internal memory.
Or not.

For those with sdcards & OSMAnd, it's easier just to match the volume name. But, you can manually change the directories out from under this editor.

But not from all editors - which is the point of bringing up editors.
BTW, I learned this the hard way, as you can see from the images below:

<https://i.postimg.cc/nr8KNVby/sdcard06.jpg> OsmAnd~ Data storage folder
<https://i.postimg.cc/mrzHRxwB/sdcard07.jpg> OsmAnd~ Move to ext sdcard
<https://i.postimg.cc/vZ1RtXhc/sdcard08.jpg> OsmAnd~ Moved to ext storage

Then, remember that you can just edit the label to anything without formatting, in Windows. There is a "label" command in MsDOS that should still be able to do the trick.

I used to write, decades ago, tutorials on MSDOS DEBUG programming, in the Peter Norton days, but it has been a long time since I messed with that.

However, to your value-added point, yes, you can change the sdcard volume
name (aka volume label) using the DOS "label" command & the File Explorer.

Here's how to change the volume name through the command prompt:
1. Win+R > cmd
2. Label P: 2025-0202 (e.g., to label it as February 2nd, 2025)
3. Press "Enter"

You can also change the volume name through File Explorer:
1. Open File Explorer:
2. Right-click on your SD card:
3. Select "Properties":
4. In the "General" tab, change the text in the "Volume Label" field:
5. Click "OK"

Both methods work without affecting the data on your SD card.
This is actually a *much better* idea than the one I had espoused!

Since this offshoot is only on the Android newsgroup, I'm gonna forward it
to the rest of the groups so that others can benefit from this useful improvement - which - I must admit - is sheer genius due to the fact that a (quick) format isn't needed (and hence, existing data isn't in jeopardy).

Note: You generally do NOT have existing data on a new sdcard though. :)

That said, it happens that I can not quadruple the storage in my tablet, because the maximum size it accepts is not that large.

Well, OK. I get that. For me, 128GB on my free Samsung works fine.
I just looked up how much it can take, and mine appears to be 1TB.

Lucky me. :) (I suspect by the time 1TB sdcards get to be about ten bucks,
I'll pine for a new phone (even as I'm happy with my free Galaxy A32-5G).

It's the iPhones that I have which always die (as AJL & I discussed earlier
in this thread) where my free ($200 MSRP) phone has a better battery than
Apple has ever put in any iPhone ever sold - where those iPhone batteries
are so bad, the EU will forbid Apple from selling their iPhone later this
year. Apple, being scared of the EU, finally upgraded the iPhone 15 to
*barely* meet the minimum charge-cycle lifetime expectations - which means
no iPhone older than that can be sold in the EU later this year.

Meanwhile, almost every Android phone not only easily met the battery charge-cycle lifetime requirements, but most *doubled* the minimum spec.
--
Fancy that: Apple puts the cheapest components they can into the iPhone.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote :

You don't use offline maps for example? Really? Seriously?
How do you navigate using your phone when there is no Internet signal?

Till today I had no idea you were talking of map editors. I was thinking text editors.

I apologize for not providing examples of which editors store their data on
the sdcard, where I openly admit I may have accidentally not provided
enough data for others to understand the complexity of the problem set.

My goal, always, is to *seamlessly* port from any one phone to any other
phone, where by "seamless", I mean that I've (brilliantly) planned years
ahead (just as I do on Windows) for the certainty of porting all my data.

It has been widely stated that there are only three certainties in life:
a. Porting your data
b. The battery will eventually meet its charge-cycle-limit death, and,
c. Taxes (even on my free phone, I had to pay 10% California sales tax)

Unfortunately, my iPhone dies sooner than my Android due to the excessively cheap batteries Apple puts into them; but at least the EU is forcing Apple
to no longer sell any iPhone that doesn't meet the bare-minimum battery charge-cycle lifetime specs - which Apple barely meets with the iPhone 15.

No, I do not use map editors on my phone, either.

Well, I hike a lot in the Santa Cruz Mountains, where I proved, long ago
how atrociously inaccurate the Open Street Maps are (which is too bad, as I *love* the concept of open source topographic maps); so I have to do a
*lot* of map editing.

Lately, even though I've written many a tutorial on how to edit map data, I generally use the free 1:24K geopdf USGS maps (which I understand are not useful to people outside of the country). I've also shown people how to navigate in every state & federal park in the USA with iOS & Android apps.

In addition, I have written many a tutorial on how to take any map PDF and
then georeference it such that it displays where you are on both iOS &
Android devices when you're nowhere near the Internet.

I've shown people how to draw a route and then how to follow that route,
where there are no street signs in the middle of the mountains out here
such that people are lost for days (due to the steep topography I guess).
<https://duckduckgo.com/?q=hiker+lost+in+santa+cruz+mountains>

It turns out that there is a *lot* of map editing to do when you're
actually using dead reckoning to get from point A to point B in mountains.

But it wasn't only map editors that I was thinking about.
It was all editors on Android that don't actually edit multimedia files.

Multimedia, as we covered separately, finds itself. :)

I use map apps that view the map, not edit them.

Well, that's understandable, but even if you never *edit* the maps, you
still have to store offline maps *somewhere*, where, they're never small.

I pity people who don't have access to portable storage, and no, the cloud
is not the same thing (which those clueless Apple trolls can't fathom).

Another editor is Keepass2Android. There are plenty of Android editors.
Most (if not almost all) my private data is stored on the sd card.

I don't "edit" my password file on the phone.

Well, to be perfectly open, as always, I "usually" do the same as I strive
to only edit the passwords kdbx file on Windows, and then I only read it on Android - but sometimes - rarely - but sometimes - I need to edit it too.

To continue to add value, I've found the most compatible Windows free
password editor to be KeepassXC (cross compatible with Mac, Win & Linux).
<https://keepassxc.org/>

I've tested *all* of them though, every single one that was ever suggested
on both the Android & Windows newsgroups, where on Android, I found that Keepass2Android appears to be the most cross compatible with KeepassXC:
<https://play.google.com/store/apps/details?id=keepass2android.keepass2android>

And, my editor by default inserts photos inside the document file.

Photo editors are a different breed of app when it comes to "finding" their >> files. I'm not sure *how* media is handled differently than, oh, say, text >> files such as GPX files or PDF files or whatever - but there is some
"magic" on a phone that seems to find all media, no matter where it is.

So media (such as images & video) I think is a special case in this regard. >>
That is, even if you changed the volume name (aka volume label) of your sd >> card, the image & video editors still seem to *find* the sd card files.

If those on this newsgroup can edify us as to why that magic only works for >> media files, and not for, oh, say, text files (such as GPX files), please
elucidate why other formats (such as PDF, gpx, kml, etc.) aren't easily
found.

Because "editor" to me is a text editor, and I was thinking of the one I use, Libre Office Writer. Ok, a word processor. If I have to edit pure
plain text files they are just a few kilobytes in size.

Yeah. I agree. %EDITOR% means a *lot* of editors, as you can see from my screenshots earlier today - where I must have hundreds of editors installed (every single one of those editors I have tested, at least briefly, myself)
<https://i.postimg.cc/NFgH18Gp/photo-editor01.jpg>

Note in that screenshot alone, you see editors of all these types:
\software\editor\3d
\software\editor\android
\software\editor\assembler
\software\editor\audio
\software\editor\calendar
\software\editor\checksum
\software\editor\codec
\software\editor\convert
\software\editor\download
\software\editor\epub
\software\editor\exif
\software\editor\hex
\software\editor\icon
\software\editor\lang
\software\editor\ocr
\software\editor\passwd
\software\editor\pic
\software\editor\pspdf
\software\editor\readthis.txt
\software\editor\screenrec
\software\editor\snapshot
\software\editor\suite
\software\editor\tts
\software\editor\txt
\software\editor\vid
\software\editor\watermark
\software\editor\xml

In any one of those top-level editing categories, are more editors, e.g.,
just for Android editors alone, that are on Windows, I have tested these:
\software\editor\android\adb
\software\editor\android\apk
\software\editor\android\app
\software\editor\android\as
\software\editor\android\cast
\software\editor\android\cpu
\software\editor\android\emu
\software\editor\android\filesharing
\software\editor\android\gra
\software\editor\android\how
\software\editor\android\ide
\software\editor\android\jre
\software\editor\android\mtp
\software\editor\android\sdk
\software\editor\android\sql
\software\editor\android\usb
\software\editor\android\vid

Arbitrarily, just the EXIF editors I've tested, are listed below:
\software\editor\exif\analogexif
\software\editor\exif\exifcleaner
\software\editor\exif\exifdatechangerlite
\software\editor\exif\exifer
\software\editor\exif\exifmanager
\software\editor\exif\exifpilot
\software\editor\exif\exiftool
\software\editor\exif\exiftoolgui
\software\editor\exif\exiftran
\software\editor\exif\exiv2
\software\editor\exif\jpeg_templates
\software\editor\exif\jpegclub
\software\editor\exif\metadata++
\software\editor\exif\readthis.txt
\software\editor\exif\sample
\software\editor\exif\vidcoder
\software\editor\exif\xnview

I'm sure most people don't test as many editors as I test, don't you think?

For example, these are the free icon editors I test as I often make my
Android icons on Windows because it's easier to edit them on Windows.
\software\editor\icon\foldermarker
\software\editor\icon\greenfish
\software\editor\icon\icofx
\software\editor\icon\iconexplorer
\software\editor\icon\jsware_iconextr
\software\editor\icon\quickany2ico
\software\editor\icon\readthis.txt
\software\editor\icon\resourcehacker

Note that people who don't do anything won't know that when you make
shortcuts in Android to settings five levels deep, you need to give those shortcuts an icon - which is where those free icon editors shine.

While most people might not edit EXIF or icons or APKs, most people find a
need to edit PostScript/PDF files, right? For that, I use these editors:
\software\editor\pspdf\acrobat
\software\editor\pspdf\calibre
\software\editor\pspdf\cutepdf
\software\editor\pspdf\fileoptimizer
\software\editor\pspdf\foxit
\software\editor\pspdf\ghoststuff
\software\editor\pspdf\msoffice2007saveaspdf_microsoft
\software\editor\pspdf\mupdf
\software\editor\pspdf\ocr
\software\editor\pspdf\pdf_text_to_audio
\software\editor\pspdf\pdf2office
\software\editor\pspdf\pdfcreator
\software\editor\pspdf\pdfsam
\software\editor\pspdf\pdfshaper
\software\editor\pspdf\pdftk
\software\editor\pspdf\pdfxchange
\software\editor\pspdf\pdf-xchange_viewer
\software\editor\pspdf\pdfxv
\software\editor\pspdf\posterazor
\software\editor\pspdf\psutils
\software\editor\pspdf\sumatra
\software\editor\pspdf\wkhtmltox
\software\editor\pspdf\wps_pdf2word
\software\editor\pspdf\xpdf

As you can see, I have tested so many %EDITORS% that I can't even count
them. For example, look at all the free screen recorders I've tested:
\software\editor\screenrec\1-cutescreenrec
\software\editor\screenrec\2-obsstudio
\software\editor\screenrec\apowerrec
\software\editor\screenrec\aviscreenclassic
\software\editor\screenrec\bsr
\software\editor\screenrec\camstudio
\software\editor\screenrec\captura
\software\editor\screenrec\chrispc
\software\editor\screenrec\debut
\software\editor\screenrec\dvdvideosoft
\software\editor\screenrec\em
\software\editor\screenrec\ezvid
\software\editor\screenrec\fdr
\software\editor\screenrec\flashback
\software\editor\screenrec\freecam
\software\editor\screenrec\gamedvr
\software\editor\screenrec\gilisoft
\software\editor\screenrec\goplay
\software\editor\screenrec\hypercam
\software\editor\screenrec\icecream
\software\editor\screenrec\ispring
\software\editor\screenrec\jing
\software\editor\screenrec\screencastomatic
\software\editor\screenrec\sharex
\software\editor\screenrec\streamobs
\software\editor\screenrec\tinytake
\software\editor\screenrec\uscreencapture
\software\editor\screenrec\vclip
\software\editor\screenrec\wink
\software\editor\screenrec\wisdom

I could go on (and on) as the major task of any platform, is, I would
wager, $EDITING! - which is why the comp.editors folks were included.

When you port Android, using Windows tools, you want all of the Android
editors to find their files, when those files are stored on the sd card.

I can link to external photos, but then, as I use Linux, I would use
relative paths or symlinks.

I love your suggestion of symlinks, but as I painstakingly explained,
nobody yet has proposed a way to do it that I know of, for Android.

Your question is posted to the editors group, and to the windows group,
so I don't have to limit my thinking to Android.

Fair enough. I agree. I apologize. I certainly don't limit myself (e.g.,
you see me comment on how Apple always tries to fuck the customer and their customer actually thinks it's a good thing when Apple doesn't even give
them the choice of an sd card slot). So I apologize for saying what I did.

You are welcome to carry the conversation in any way you feel is
appropriate to the topic and to the newsgroups that are in on the convo.

If you can get symlinks to work on the sdcard for Android, you'd be a far
more intelligent man than I am, so I'll patiently await how you do it.

Also I *never* edit a file residing in flash storage. I edit in main
storage in the computer, then copy the result over to flash media if
needed.

Hmm... how do you edit GPX or KML files?

I don't.

I thought you were talking of text files.

See above. I have, oh, I can't even count how many... let's just say
"hundreds" of editors - and that's only Windows that I listed above.

I've also tested every free editor ever suggested on the Android ng.

And on the iPhone newsgroup too - although - in a way - Apple makes that
easy because almost nothing useful on the iOS platform is actually free.

Funny point about Apple: The Apple mothership tracks you *more* than even Google does, where, for example, your AppleID is inserted into every IPA
you install on an iOS device! So you're *purchasing" even a *free* IPA!

That way Apple can track everything you do with that IPA.
Google can't do that with APKs. Windows can't do it with EXE's.

Only Apple does that sinister tracking of everything you edit with.
Sigh. (What bothers me isn't Apple but people *believing* their lies!)

Do you copy them from the sd storage to main storage just to edit them?
Why?

Because the wear in flash cards is limited, and using an editor in such media stresses them.

Hmm... I get what you are saying, but I've never worried about the wear of sdcards. I'm sure it happens. But how much does it happen? I don't know.
<https://duckduckgo.com/?q=how+long+do+sdcards+really+last>

Anything I don't know, I look up, so here's what I found just now.
Factors influencing SD card wear:
a. Frequency of writes
b. Amount of data written
c. Quality of the card
d. Wear leveling
e. Environmental factors (e.g., temperature & physical damage)

That having been said, this guesstimates about a 10-year life for sdcards:
<https://www.howtogeek.com/887545/how-long-do-sd-cards-last/>

Interestingly, one recommendation that article above makes is:
f. Avoid filling it to capacity

Interesting value added, is it not?

Thanks for bringing up the type of editors being important, as I learned a
lot simply by responding to your valid concerns. Much appreciated!

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 21:34:45 -0000 (UTC), Marion wrote:

As I recall, Blender was extremely powerful; but I was looking at it for
3D CAD purposes ...

It covers a lot of DCC application areas, as should be evident by now.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 14:43:10 +0100, Carlos E.R. wrote:

On 2025-02-02 04:21, Lawrence D'Oliveiro wrote:

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote:

Also I *never* edit a file residing in flash storage.

Does your system not have an SSD?

Mmm. Certainly, but it is another kind, designed for intensive use.

You didnrCOt say which kind.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-03 01:01, Lawrence D'Oliveiro wrote:

On Sun, 2 Feb 2025 14:43:10 +0100, Carlos E.R. wrote:

On 2025-02-02 04:21, Lawrence D'Oliveiro wrote:

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote:

Also I *never* edit a file residing in flash storage.

Does your system not have an SSD?

Mmm. Certainly, but it is another kind, designed for intensive use.

You didnrCOt say which kind.

I don't call an SSD a flash media.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-03 00:42, Marion wrote:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote :

...

I use map apps that view the map, not edit them.

Well, that's understandable, but even if you never *edit* the maps, you
still have to store offline maps *somewhere*, where, they're never small.

I don't need to store the entire map of the USA, or the entire Europe
either. Just Spain, Ontario, and Quebec, to be precise. Actually, I accidentally downloaded to my phone a lot of podcasts and they use more gigabytes than my maps.


...

Do you copy them from the sd storage to main storage just to edit them?
Why?

Because the wear in flash cards is limited, and using an editor in
such media stresses them.

Hmm... I get what you are saying, but I've never worried about the wear of sdcards. I'm sure it happens. But how much does it happen?-a I don't know. <https://duckduckgo.com/?q=how+long+do+sdcards+really+last>

Anything I don't know, I look up, so here's what I found just now.
-aFactors influencing SD card wear:
-aa. Frequency of writes
-ab. Amount of data written -ac. Quality of the card
-ad. Wear leveling
-ae. Environmental factors (e.g., temperature & physical damage)

Flash media, ie, usb sticks or storage cards, do not have wear
levelling. Ok, maybe some units out there do, but mere mortals don't
have them. SSDs do.

I have seen USB sticks die "soon" because they were used frequently for
office use, I mean, normal word or excel files that were edited directly
in there. I don't know how many writes you can do, but it is limited and
it is reachable.

I also have seem storage cards used on tiny computer (think a Pi) die.
Also heard of some Tesla car failing because the internal computer
storage died of so much use, simply because of frequent log writing.

It does happen.

The internal media of phones is much more resilient than the plugable
cards, by the way. Unless you happen to have crap phones and excellent
cards.

That having been said, this guesstimates about a 10-year life for sdcards: <https://www.howtogeek.com/887545/how-long-do-sd-cards-last/>

Interestingly, one recommendation that article above makes is:
-af. Avoid filling it to capacity

That's well known, but it is only true if the media has wear levelling.

Interesting value added, is it not?

Thanks for bringing up the type of editors being important, as I learned a lot simply by responding to your valid concerns. Much appreciated!

Welcome.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used
it to edit non-text files.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 02:21:36 +0100, Carlos E.R. wrote:

Flash media, ie, usb sticks or storage cards, do not have wear
levelling. Ok, maybe some units out there do, but mere mortals don't
have them. SSDs do.

IrCOm sure all flash-based media has to have some degree of wear-levelling. Though some may have more of it than others.

Linux has filesystems that are designed to operate natively on media that needs wear-levelling (e.g. jffs2, nilfs2), that include provision for that automatically in their normal operation.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 01:59:39 +0100, Carlos E.R. wrote:

On 2025-02-03 01:01, Lawrence D'Oliveiro wrote:

On Sun, 2 Feb 2025 14:43:10 +0100, Carlos E.R. wrote:

On 2025-02-02 04:21, Lawrence D'Oliveiro wrote:

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote:

Also I *never* edit a file residing in flash storage.

Does your system not have an SSD?

Mmm. Certainly, but it is another kind, designed for intensive use.

You didnrCOt say which kind.

I don't call an SSD a flash media.

What would you call it, then?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 02/02/2025 16:37, Kenny McCormack wrote:

In article <vnoa2f.qag.1@ID-201911.user.individual.net>,
Frank Slootweg <this@ddress.is.invalid> wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 02.02.2025 15:50, Carlos E.R. wrote:

[...]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

To be clear, Android's native filesystem is not FAT (but ext4), but if
you use a (Micro)SD-card in an Android device (which is partly the
subject of this ... ahem ... 'thread'), then the filesystem on that card
is FAT (assuming it's not used as an extension of Internal Storage
('disk' space)).

Yes, all true. Interestingly, at least the one time I tested this, when I formatted an SD card to ext4, then inserted it into a phone, it did not recognize it. Odd, because obviously, it *can* recognized ext4
filesystems. But it only seems to be able to do FAT on the SD card.

Interesting. I didn't know about the FAT/ext4 file system issue.

Seems the latest high-capacity cards (SDXC, SDUC) use exFAT (<https://en.wikipedia.org/wiki/SD_card>). Actually, SDXC cards have
been around for quite a time; those should be recognisable in a phone.
What make/age of phone was yours?
--
Jeff
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 00:01:09 -0000 (UTC), Lawrence D'Oliveiro wrote :

As I recall, Blender was extremely powerful; but I was looking at it for
3D CAD purposes ...

It covers a lot of DCC application areas, as should be evident by now.

Since this is an Editor group, discussing Android on Windows... I am going
to try to illustrate below what is trivial on Android is difficult on
Windows.

If anyone can make that statement false, I'd be *happy* to hear how!

Windows Blender is, in a word, powerful.
But it's damn hard to use.

Meanwhile, the Android apps I had suggested are, um, er, shall we say
almost foolproof? All you do is pick a photo & you cartoonify it.

Takes mere seconds.
And no skills whatsoever.

Sure, not much control.
But what is trivial on Android, is damn near impossible to do on Windows.

At least as far as anyone on these newsgroups has shown in this thread.
And, trust me, I've tested *every* cartoonify program suggested here.

Especially on Android, where I've tested (virtually) them all.

Since I've tested, oh, I don't know, maybe two dozen of them, I'm aware
that there are actually few offerings - it is just one company seeding the
apps with the same AI but with slightly different branding, so there are
really fewer than a half dozen to choose from to cartoonify faces.

You don't get a whole lotta choices on results either, but you get enough
that you don't really need too many as they do a pretty good job I think.

At least for a funny joke... or for a social media avatar (or xface?).

Let me make an example for you. I need someone's face? Googling...

OK. Let's take the first image of Demi Moore in this article today:
<https://www.thecut.com/article/review-the-substance-movie-gets-aging-wrong.html>

Here is that face photo of Demi Moore as our starting point image:
<https://pyxis.nymag.com/v1/imgs/d2e/a37/d87bed8d2c9aefe83c99c4e094d5649622-the-substance.rhorizontal.w700.jpg>
Actually, to fool (some) watermark algorithms, I'll stretch it:
<stretched>

Note that I can't use the external sdcard for this task because the Android cartoonify apps use the phones's sdcard0 storage - which is mounted onto Windows as the Q: drive (as the P: drive is the sdcard1 portable storage).

With that in mind, I'm going to run the entire conversion on the Q: drive
from Windows, but the Android CPU will be the underlying AI cartoonify
engine so I'll be connecting all three newsgroups in this editing task.

a. A cartoonify editor (to convert the image to a cartoonified avatar)
b. Windows (to do all the snapshots & watermark removal tasks)
c. Android (to run the AI cartoonify engine on the MediaTek CPU)

In order of my personal cartoonify app preferences...

0. Original <https://i.postimg.cc/HLMKjCRH/original.jpg>
(Stretched) <https://i.postimg.cc/63X9pcHj/original01.jpg>

1. Voila (/sdcard0/Pictures/Voila/.)
<https://i.postimg.cc/P5DsvZvB/viola01.jpg>

2. ToonMe (/sdcard0/Pictures/ToonMe/.)
<https://i.postimg.cc/VLbHKwst/toonme01.jpg>

3. PhotoLab
<https://i.postimg.cc/vT52H7Nz/photolab01.jpg>

4. ToonArt (/sdcard0/Pictures/.)
<https://i.postimg.cc/qvWKjfRN/toonart01.jpg>

5. CartoonPhoto (/sdcard0/Pictures/Cartoon_Photo/.)
<https://i.postimg.cc/Dy8mDCRL/cartoonphoto01.jpg>

6. Comica (/sdcard0/Pictures/comica/.)
<https://i.postimg.cc/d1sV9n87/comica01.jpg>

7. PhotoRoom (/sdcard0/Pictures/PhotoRoom/.)
<https://i.postimg.cc/cCKZDz6J/photoroom01.jpg>

My main point is that this kind of ease of use doesn't exist on Windows. Unfortunately. At least as far as anyone on these newsgroups knows.

Note for the above I used Windows tricks, Android tricks, and (free)
Android cartoonify editors (albeit I have to block their ads with DNS
blocking tricks) where I had to use a few screenshotting tricks too.

Nonetheless, it was so easy to cartoonify the original image, that anyone
can do it - which is why I stated that I've never seen something that good
on WIndows - although you did find something far more powerful.

But the point here is what is trivial on Android, is extremely difficult to
do on Windows - which is why I had said the statement that I did.
--
The whole point of Usenet is to find people who know more than you do
so that you learn from them; otherwise, you teach everyone else what you
know so that someday, they will be able to teach you something also.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 02:21:36 +0100, Carlos E.R. wrote :

I use map apps that view the map, not edit them.

Well, that's understandable, but even if you never *edit* the maps, you
still have to store offline maps *somewhere*, where, they're never small.

I don't need to store the entire map of the USA, or the entire Europe either. Just Spain, Ontario, and Quebec, to be precise. Actually, I accidentally downloaded to my phone a lot of podcasts and they use more gigabytes than my maps.

Funny thing about living in California. As you're well aware, I've tested
every free map app that exists on Android, and most of them have a "state" download, where if you download California, it's huge compared to, oh, say, Rhode Island.

Some map apps give you sections of states - but most are organized by
states. Luckily the USGS georeferenced PDF maps are by quadrangles.

And the parks maps are by the park names, so that works out well.

To continue to add value, anyone on either iOS or Android can load any georeferenced PDF into either of these free programs to navigate with:

*Avenza Maps* Offline Mapping by Avenza Systems Inc., In-app purchases
Free, ad free, 4.6 star, 72.6K reviews, 1M+ Downloads
<https://www.avenza.com/avenza-maps/>
<https://play.google.com/store/apps/details?id=com.Avenza>
<https://apps.apple.com/app/apple-store/id388424049>

*Paper Maps* by Abbro Inc, In-app purchases
Free, ad free, 5K+ Downloads
<https://www.paper-maps.com/>
<https://play.google.com/store/apps/details?id=ca.abbro.androidmap>
<https://apps.apple.com/app/nextmap/id1147385120>

Of course, you may need to *save* tracks also, especially if you want to
get to where you were before and then branch off in another direction.

Three privacy aware offline GPS track loggers without GSF that save tracks
to SD subfolders (without needing Wi-Fi Precise Location turned on).

1. GPS Logger by BasicAirData (free, no ads)
No Google GSF dependency
Precise location not required!
No maps (good!) as it has no Internet capability
Can set output folder to an sd card subfolder

https://play.google.com/store/apps/details?id=eu.basicairdata.graziano.gpslogger

2. GPSLogger II - AIO by Mathias Marquardt (free, no ads)
No Google GSF dependency
Precise location not required!
Has maps so be careful when exporting to the Internet
https://play.google.com/store/apps/details?id=com.emacberry.gpslogger

3. OSM Tracker for Android
No Google GSF dependency
Can set output folder to an sd card subfolder
Can display OSM map under track but needs Internet connection to do
that.
https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)
https://github.com/labexp/osmtracker-android
https://f-droid.org/en/packages/net.osmtracker/

I'm not sure about this fourth app because it asks for Wi-Fi Precise
Location even though it isn't built with Google's GSF gms API's;
but it seems to work without that being granted to it.

4. OpenTracks
No Google GSF dependency
It asks for Precise location but it seems to work without it being
granted.
Can set output folder to an sd card subfolder
https://f-droid.org/en/packages/de.dennisguse.opentracks/
Warning: Has a payware googleplaystore version

https://play.google.com/store/apps/details?id=de.dennisguse.opentracks.playstore

These failed because they required the GSF gsm spyware to be running.

a. LD-Log Lite - GPS Logger by A. Wedemeyer (free, no ads)
No Google GSF dependency
Yet Wi-Fi precise location is required!
Can set output folder to an sd card subfolder though
Can import offline maps too so it's too bad it requires precise location
https://play.google.com/store/apps/details?id=com.aw.ldlogFree

b. Geo Tracker GPS tracker by Ilya Bogdanovich
Requires GSF

https://play.google.com/store/apps/details?id=com.ilyabogdanovich.geotracker

c. GPS Tracker by GPS-server.net
No Google GSF dependency
But it uploads tracking data to an Internet server
https://play.google.com/store/apps/details?id=net.gpsserver.gpsstracker

d. Ultra GPS Logger Lite by FlashLight
Requires GSF

https://play.google.com/store/apps/details?id=com.flashlight.lite.gps.logger

e. GPS Logger by Joakim Ewenson
Requires GSF
https://play.google.com/store/apps/details?id=se.ewenson.gps_logger

f. eTrack GPS by Eagle Co
Requires GSF
https://play.google.com/store/apps/details?id=vip.etrack.gps

g. Trailblazer by Andrew and Derek
Requires GSF

https://play.google.com/store/apps/details?id=com.andrewandderek.trailblazer

h. GPS Waypoints by Bluecover Technologies
Requires GSF
https://play.google.com/store/apps/details?id=pt.bluecover.gpsegnos

And lots others that I tested, all of which required Wi-Fi Precise
Location tacking in order to work even though there's absolutely no
need for Wi-Fi scanning in a backcountry offline GPS track-saving app.

Why should an offline backcountry track saver require Wi-Fi to run?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 15:44:38 +0100, Janis Papanagnou wrote :

You again stirred my curiosity - since I don't know about the Android
and its file-editors peculiarities... - How does Android recognize the
path with the (arbitrary) "A1B1-C1D1" and "A2B2-C2D2" path components
but not a generic (a fixed) one?

Well, I wish I understood why *some* Android file managers show those
cryptic identifiers, and yet other Android file managers show '0000-0001'.

There must be someone out there who understands why, but it's not me (yet).

Take a look at these screenshots I made for you to illustrate the question.

0. We're starting with an sdcard which was formatted to 0000-0001
Then we test only the 1st 4 file managers in my homescreen "file' folder
<https://i.postimg.cc/HszHTvkZ/label.jpg>

2. Notice the first file manager (OwlFiles) shows both the cryptic label
and the user-defined label (for reasons completely unknown to me).
<https://i.postimg.cc/PqGS9TnB/owlfiles.jpg>

3. The second file manager (Round Sync) is completely fooled by the label!
<https://i.postimg.cc/C1rkysfz/roundsync.jpg>

4. The third file manager (Mix Explorer) is almost completely fooled.
<https://i.postimg.cc/26yLxLXm/mixexplorer.jpg>

5. The fourth file manager (ZArchiver) isn't fooled in the least.
<https://i.postimg.cc/0yvf0ZGs/zarchiver.jpg>

I wish I understood those results.
But I don't.

Does anyone?

Why do some file managers show 0000-0001, while others show both, and yet, still others only show the cryptic volume label & not the 0000-0001?

I openly admit that I'm befuddled by those results.
Does someone know more about this than I do?

If so, please explain why we're seeing what we're seeing above.
That would add value for sure.

TIA
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Carlos E.R., 2025-02-03 01:59:

On 2025-02-03 01:01, Lawrence D'Oliveiro wrote:

On Sun, 2 Feb 2025 14:43:10 +0100, Carlos E.R. wrote:

On 2025-02-02 04:21, Lawrence D'Oliveiro wrote:

On Sat, 1 Feb 2025 20:54:19 +0100, Carlos E.R. wrote:

Also I *never* edit a file residing in flash storage.

Does your system not have an SSD?

Mmm. Certainly, but it is another kind, designed for intensive use.

You didnrCOt say which kind.

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not different to that of SD cards.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <m0br40Ff8v9U2@mid.individual.net>,
Arno Welzel <usenet@arnowelzel.de> wrote:
...

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not >different to that of SD cards.

Chill out, man.

People often use terminology in idiosyncratic ways. That doesn't make them wrong. I understand Carlo's frame of reference, and I accept it. You
should do likewise.

Just for one example:
In some circles, unless it is a 4 footed mammal, it is not an "animal".

I assume Carlo's use of terminology is similar.
--
To be evangelical is to spend every waking moment hovering around
two emotional states: fear and rage. Evangelicals are seriously the
angriest and most vicious bunch of self-pitying, constantly-moaning
whinybutts I've ever encountered.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-03 14:09, Kenny McCormack wrote:

In article <m0br40Ff8v9U2@mid.individual.net>,
Arno Welzel <usenet@arnowelzel.de> wrote:
...

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not
different to that of SD cards.

Chill out, man.

People often use terminology in idiosyncratic ways. That doesn't make them wrong. I understand Carlo's frame of reference, and I accept it. You
should do likewise.

Just for one example:
In some circles, unless it is a 4 footed mammal, it is not an "animal".

I assume Carlo's use of terminology is similar.

This minute, I do not know how to name SSDs. I'm confused.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-03 11:40, Marion wrote:

On Sun, 2 Feb 2025 15:44:38 +0100, Janis Papanagnou wrote :

You again stirred my curiosity - since I don't know about the Android
and its file-editors peculiarities... - How does Android recognize the
path with the (arbitrary) "A1B1-C1D1" and "A2B2-C2D2" path components
but not a generic (a fixed) one?

Well, I wish I understood why *some* Android file managers show those
cryptic identifiers, and yet other Android file managers show '0000-0001'.

There must be someone out there who understands why, but it's not me (yet).

Take a look at these screenshots I made for you to illustrate the question.

0. We're starting with an sdcard which was formatted to 0000-0001
-a Then we test only the 1st 4 file managers in my homescreen "file' folder
-a <https://i.postimg.cc/HszHTvkZ/label.jpg>

2. Notice the first file manager (OwlFiles) shows both the cryptic label
-a and the user-defined label (for reasons completely unknown to me).
-a <https://i.postimg.cc/PqGS9TnB/owlfiles.jpg>

3. The second file manager (Round Sync) is completely fooled by the label!
-a <https://i.postimg.cc/C1rkysfz/roundsync.jpg>

4. The third file manager (Mix Explorer) is almost completely fooled.
-a <https://i.postimg.cc/26yLxLXm/mixexplorer.jpg>

5. The fourth file manager (ZArchiver) isn't fooled in the least.
-a <https://i.postimg.cc/0yvf0ZGs/zarchiver.jpg>

I wish I understood those results.
But I don't.

Does anyone?

Why do some file managers show 0000-0001, while others show both, and yet, still others only show the cryptic volume label & not the 0000-0001?

I openly admit that I'm befuddled by those results.
Does someone know more about this than I do?

If so, please explain why we're seeing what we're seeing above.
That would add value for sure.

I suspect some are using the UUID. But I don't understand how different
file managers can show different results, it should be the operating
system who names things in an unique way. Maybe there are two different
trees and they can choose.

Maybe the file manager is mounting the card? Why? It should be already
mounted by Android.

It is a non issue for me, as I can no longer use cards on my phones.
Maybe on the next tablets.


Huh, the filemanager I use is Ghost Commander. Sorry, I can't find the official name. Setup/Aplications does not list it, Play Store does not
list it, but I have just run it. Unless it has been renamed to Total Commander.

Google finds a site:

https://sites.google.com/site/ghostcommander1/About

but I don't know if this site is faked.

Weird.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-02 17:29, Frank Slootweg wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 02.02.2025 15:50, Carlos E.R. wrote:

[...]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

To be clear, Android's native filesystem is not FAT (but ext4), but if
you use a (Micro)SD-card in an Android device (which is partly the
subject of this ... ahem ... 'thread'), then the filesystem on that card
is FAT (assuming it's not used as an extension of Internal Storage
('disk' space)).

Are you sure it is ext4?

On old phones, when connected to computer, the internal storage was
taken over directly by the computer, and it did appear to be FAT.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 02/03/2025 8:34 AM, Carlos E.R. wrote:

On 2025-02-03 14:09, Kenny McCormack wrote:

In article <m0br40Ff8v9U2@mid.individual.net>,
Arno Welzel-a <usenet@arnowelzel.de> wrote:
...

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not
different to that of SD cards.

Chill out, man.

People often use terminology in idiosyncratic ways.-a That doesn't make
them
wrong.-a I understand Carlo's frame of reference, and I accept it.-a You
should do likewise.

Just for one example:
In some circles, unless it is a 4 footed mammal, it is not an "animal".

I assume Carlo's use of terminology is similar.

This minute, I do not know how to name SSDs. I'm confused.

A rose is a rose, as long as it does the job you want what does it
matter what it is called. I have many useful devices called Thingamajig.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote at 15:04 this Sunday (GMT):

On 02.02.2025 15:50, Carlos E.R. wrote:

[snip]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

Janis

It's hard to stop momentum, sometimes. Windows refusing to switch to a different FS for external medium also doesn't help.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 03:01:22 -0000 (UTC), Lawrence D'Oliveiro wrote :

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used
it to edit non-text files.

Decades ago I wrote a tutorial for how to use MSDOS DEBUG to edit files.

Funny story... while I have tons of editors for all sorts of file types,
the only two editors I habitually use on Windows are gVim & Notepad++.

The use of gVim is obvious for anyone else who came up through the ranks *before* Emacs was a thing; but the use of Notepad++ is less obvious
perhaps. Once is a great while, I use a hex editor or qedit on text files.

What I love about Notepad++ is its shortcuts.xml substitution capability is fantastic, such that in a keystroke sequence, you can wipe out all the
special "curly" characters to replace them with standard characters.

For me, this is important as I do a lot of cutting and pasting, and yet I
want all the characters to be consistent. Plus, I don't own a newsreader.

My "newsreader" is simply a set of telnet-based scripts long ago ported
from Centos and then to Ubuntu and then to Windows over the many years.

For example, I don't see headers (so they're meaningless to me), as all I
see is the body of the message (with an attribution line at the top).

So I don't even know who I am, nor whom I'm responding to unless I
purposefully keep track - as what matters to me is only what someone says.

I do a lot of pastes from research, which I do to purposefully help others.
a. I run the research & copy pertinent details
b. (if necessary) I paste research into Notepad++ to clean it up
c. Then I paste it into the gVim session & send the article via telnet

Special characters show up funnily in the vi editor so Notepad++ replaces
them in a quick keystroke sequence for pasting back into the gVim session.

The fact I type better than most secretaries do helps along with the fact
that gVim is the most efficient hands-on editor that I know of for Windows.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2/3/2025 8:34 AM, Carlos E.R. wrote:

This minute, I do not know how to name SSDs. I'm confused.

Lawrence just spends his days trying to one-up other people,
especially with tech trivia. Why do you let him?

SSD is unambiguous. Like you, I
don't call it a flash drive. I don't call anything flash. There
are USB sticks, SSDs and SD cards. The type of data strorage
they use is not a practical concern. Those terms are specific
in terms of IDing the item.



--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 2/3/2025 8:34 AM, Carlos E.R. wrote:

On 2025-02-03 14:09, Kenny McCormack wrote:

In article <m0br40Ff8v9U2@mid.individual.net>,
Arno Welzel-a <usenet@arnowelzel.de> wrote:
...

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not
different to that of SD cards.

Chill out, man.

People often use terminology in idiosyncratic ways.-a That doesn't make them >> wrong.-a I understand Carlo's frame of reference, and I accept it.-a You
should do likewise.

Just for one example:
In some circles, unless it is a 4 footed mammal, it is not an "animal".

I assume Carlo's use of terminology is similar.

This minute, I do not know how to name SSDs. I'm confused.

This could be a USB flash stick, a Solid State Drive (SSD). The SSD
uses Host Based Memory ("cheap" SSD), or the SSD can have its own
1GB DRAM chip to hold the virtual to physical mapping table. USB flash
sticks don't do that, and the interface speed on USB flash makes that
sort of idea impractical.

PHY and protocol
-------------------- controller ------- Toggle Flash TLC/QLC

This could be an SD or an eMMC chip.

PHY and protocol
-------------------- controller ------- Toggle Flash TLC/QLC

\________ same plastic package _______/

The controller ranges from an 8085, to a quad core ARM. The SSD
would have static and dynamic wear leveling, the USB stick, not.

The flash chip could be consumer grade, or the Enterprise flash
with the 6x write cycles that Micron makes.

Flash could last forever... if we could anneal it to repair
defects in the cells. But we're not there yet, and might never make
it there.

The toggle flash could be replaced with Optane, but that's discontinued
and has higher power dissipation.

A single flash die, can have vertical lines of storage bits, arranged
in up to 232 layers.

https://www.mdpi.com/computers/computers-06-00027/article_deploy/html/images/computers-06-00027-g010-550.jpg

The die can be stacked, with thru substrate vias. Sixteen die inside
one IC package. This is why a USB flash stick can be 32GB in a single
die, and an SSD can use 1TB chips (two chips) to make a 2TB SSD drive.
In the larger flash chips, it's even possible there are multiple
toggle channels in the same package (the controller might have eight
channels, to get the bandwidth, and with the limited number of chips
in the SSD, the chip needs more channels to flesh out the controller).
Raising the speed of a toggle channel too high, would lead to
local heating problems. The dies being fastened together are paper
thin (maybe 500u), and for some of the tech we've got today, they actually
put a piece of dummy silicon up against the thin ones, for support.
While the advert says the devices can take 1000G shock, don't
push your luck :-) Things like this are only possible, because
the thermal coefficient of expansion (TCE) of all the layers, is the same.

https://www.electronicspecifier.com/cms/images/TSV.jpg

Today, SSD drives are hardly ever full any more. The SSD in the other
machine, a Lexar NS100, it's likely a controller chip, and one stacked die flash,
and the PCB is much shorter than the 2.5" drive package. There is a lot
of air in there. And if you're thinking of opening one up, you can,
but some of them use thermal tape, and you'll rip the tape.

Bottom to top: Controller, DRAM, Flash chip

https://images.anandtech.com/galleries/2930/DSC_1058_575px.jpg

Secondary side: Flash chip over top of other flash chip (clam shell),
two electrical loads per toggle channel.

https://images.anandtech.com/galleries/2930/DSC_1059_575px.jpg

This one has some tapes. The tape that is doing something, is
over top of the controller. The controller with the ARM cores.

https://images.anandtech.com/doci/12263/imgp0157.jpg

1TB drive on the left, 4TB drive on the right.

https://images.anandtech.com/doci/16480/IMGP9045_575px.jpg

We were promised 16TB SSDs, but they were yanked before reaching retail. Highest capacity controller chip currently is 100TB, but no device
has been built yet that uses all the addressing capability.
You couldn't afford to buy it, anyway. That's part of the reason
they don't make retail high capacity drives, pricing and market
uptake. 100TB drives continue to cost as much as a small car
(3.5" drive, modular internal construction, price never given in adverts).

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sun, 2 Feb 2025 15:50:17 +0100, Carlos E.R. wrote:

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Not for its internal storage. It would only use that for media that would
be exchanged with other computers.

For internal storage, it can use any of the available Linux-supported filesystems.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

IrCOm sure you can format an SD card or USB stick with a Linux-native filesystem like ext4, stick it into your Android device, and have it recognized.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 15:16:42 +0100, Carlos E.R. wrote:

On old phones, when connected to computer, the internal storage was
taken over directly by the computer, and it did appear to be FAT.

YourCOre thinking MTP. My old phone supports that as well. ItrCOs a file-level protocol, so it doesnrCOt expose the internal storage at the sector level.

My even older phone let the microSD card be accessed by an external
computer directly at the sector level. That was in FAT format, but it was separate from the phonerCOs internal storage.

No Android phone is going to expose its OS installation area for any
external access at the sector level.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 19:00:02 -0000 (UTC), candycanearter07 wrote:

It's hard to stop momentum, sometimes. Windows refusing to switch to a different FS for external medium also doesn't help.

The problems are all with the inflexibility of Windows itself. Instead of having a pluggable VFS layer that is agnostic to different filesystem
formats, Linux-style, too many of its filesystem features are specifically tied to one filesystem format, namely NTFS.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 2/3/2025 2:00 PM, candycanearter07 wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote at 15:04 this Sunday (GMT):

On 02.02.2025 15:50, Carlos E.R. wrote:

[snip]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

Janis

It's hard to stop momentum, sometimes. Windows refusing to switch to a different FS for external medium also doesn't help.

On hardware, partition tables exist, to give a "hint" what
subset of file systems might be involved. The 0x07 for
example, might be NTFS/HPFS/ExFAT. You then have to look
at the first sector in the partition, to determine what it is exactly.
There weren't enough codes to go around, which is why the codes today,
lack the precision they once had.

On GPT, a partition type could be declared as a Basic Data Type,
then you again have to check the header sector for the details.
On Windows, you see the BLKID and the GUID. On Linux, the
gdisk utility hides the GUID (ugly) string and shows you some
fake (pseudo) codes, such as 0x0700 for a Basic Data Partition.
But once you get into the GPT partition table with your hex editor,
you'll see that the two entries do not involve "0x0700".

Hardware devices do not need to have a partition table.
You can lay a file system into a hardware device without one.
Then the OS has to try all of its filesystem types, for a match
on the header sector.

SD cards have certain expectations of filesystems, based on what
wears the SD the least. That's how FAT32 or ExFAT get on the card.
Journaled filesystems are a non-preferred choice. Neither NTFS nor EXT4
are preferred for an SD.

I don't know what the OS policy is, when the OS discovers a filesystem
outside [FAT32, ExFAT]. FAT32 is needed because the devices could be
larger ones. Maybe at some point in the past, an SD had a
small enough capacity that FAT12 or FAT16 would work.

You can use the "disktype" utility on Linux, to indicate what is
on a hardware device. I use the Cygwin version of that utility on
Windows for that purpose.

sudo disktype /dev/sda
disktype.exe /dev/sda # because it's Cygwin, it uses a non-Windows namespace

I would take the SD out of my camera right now and run it, but
it's just going to be a raw FAT32. My camera isn't new enough
to know what ExFAT is.

And you don't even *format* an SD on your desktop OS. If you're
using it in a camera, it is the responsibility of a camera menu
item to "format" inserted media. This ensures first and foremost,
that the media works in the camera. The computer end has a lot
more flexibility regarding access. But based on what cameras do
to SD, there isn't going to be a problem mounting an SD that
was formatted by the camera.

The behavior could also change, depending on the device used.
Maybe when a camera with an SD is plugged in, a different handler
(PTP/MPT) handles the camera end, than when a USB stick with SD hole
in it, presents an SD. These are experiments you can run,
as an experienced forensic expert :-)

Someone with a wider collection of hardware, can run these
experiments for me. I don't have any MTP devices, I also
don't have any smartphone to play with.

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 19:58:39 -0500, Paul wrote:

Hardware devices do not need to have a partition table.

This may be an OS-dependent thing. On Unix and Linux systems, I have had
no problem formatting an entire block device as a single volume with no partition table. Windows is a bit more picky.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 2/3/2025 8:15 PM, Lawrence D'Oliveiro wrote:

On Mon, 3 Feb 2025 19:58:39 -0500, Paul wrote:

Hardware devices do not need to have a partition table.

This may be an OS-dependent thing. On Unix and Linux systems, I have had
no problem formatting an entire block device as a single volume with no partition table. Windows is a bit more picky.

Windows is a bit picky about the USB Mass Storage fixed or removable bit (RMB). That's part of it.

Most USB sticks claim they are removable, except a few which
report they are fixed disk. When you use a USB enclosure with
a SATA drive inside it, that reports as a fixed disk as well.

If an MBR has four partitions on it (as in MSDOS partitioning),
then the Windows mounter will mount all four partitions (as long
as they are Windows types, or, an IFS is installed in the OS
to extend the capability). It's not clear, if a partition becomes un-selectable, whether a "letter" can be assigned to a partition.
In some cases, even a RAW partition can have a letter assigned, but
if you do that and then access the letter in Windows, it will
immediately request that you format the partition.

When the stick is removable, it might only support "the first partition
it finds". For example, some hybrid boot USB keys, the mounter
finds a 2MB partition with something no one cares about in it,
and mounts that. Leaving a much larger partition unmounted and
unobservable (from Disk Management at least).

I saw an announcement in some tech news, that the removable (RMB declaration) stick behavior would change, but I don't think I have noted that while
using the sticks. I don't generally put four partitions on a USB stick,
neither do I install OSes that might be doing a high number of writes
to the media -- I've had several TLC USB keys fail, and don't want any
more to fail.

https://www.elevenforum.com/t/windows-11-only-allowing-access-to-first-partition-on-usb-sticks.18333/

"Windows 10 has allowed access to all partitions on USB sticks
since the Creators Update but Windows 11 seems to have gone back
to only allowing access to the first partition. Only first
partition show up in File Explorer and no way of mounting the
other partitions using Disk Management as all the options are
greyed out when right clicking them."

It's very much an experimenters paradise.

*******

The test USB stick in the case, did the same thing under Win10 and Win11.
The two primary partitions mounted.

S:\disktype>disktype /dev/sdb

--- /dev/sdb
Block device, size 58.44 GiB (62746787840 bytes)
DOS/MBR partition map
Partition 1: 46.36 GiB (49774854144 bytes, 97216512 sectors from 2048, bootable)
Type 0x0C (Win95 FAT32 (LBA))
Windows 95/98/ME boot loader
FAT32 file system (hints score 5 of 5)
Volume size 46.34 GiB (49759518720 bytes, 1518540 clusters of 32 KiB) Partition 2: 12.08 GiB (12969836544 bytes, 25331712 sectors from 97218560)
Type 0x07 (HPFS/NTFS)
NTFS file system
Volume size 12.08 GiB (12969836032 bytes, 25331711 sectors)

[Picture]

https://i.postimg.cc/qM68Wb6w/ubu-stick-experiment.gif

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 15:14:13 +0100, Carlos E.R. wrote :

Huh, the filemanager I use is Ghost Commander. Sorry, I can't find the official name. Setup/Aplications does not list it, Play Store does not
list it, but I have just run it. Unless it has been renamed to Total Commander.

Google finds a site:

https://sites.google.com/site/ghostcommander1/About

but I don't know if this site is faked.

Hi Carlos,

As you're aware, I've tested all the free Android file managers, such that
I have both Total Commander & Ghost Commander installed. As I recall, Christian Ghisler wrote the former while the latter is open source stuff.

Since I scrape the Google Play Store repository anonymously (without
logging in) I can see that Total Commander still exists in the repo.
<https://play.google.com/store/apps/details?id=com.ghisler.android.TotalCommander>

However, I do see that the Google Play version of Ghost Commander is gone.
<https://play.google.com/store/apps/details?id=com.ghostsq.commander>

But you can see from my screenshots I have Ghost Commander installed.
It sees *both* the Volume Name Windows formatted, plus the cryptic name.
<https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

BTW, my version of Ghost Commander is v1.62.3 and when I click on the Help
from inside of that app, it takes me to that URL so it's legitimate.
<https://sites.google.com/site/ghostcommander1/>

That same help inside the app says the source code is located here:
<https://sourceforge.net/projects/ghostcommander/>

At that sourceforge site is a green "DOWNLOAD" button which goes to
<https://sourceforge.net/projects/ghostcommander/files/latest/download>

That seemed to work when I tested it just now from Windows:
<https://phoenixnap.dl.sourceforge.net/project/ghostcommander/Betas/Ghost%20Commander%201.64.1b2.apk>
Name: Ghost Commander 1.64.1b2.apk
Size: 5005025 bytes (4887 KiB)
SHA256: B574F966938A74B9EBF9210E803DBF0856087C65DEF5E63543A120BC3A28B7B5

What I do NOT understand is why I see *both* the 0000-0001 that Windows formatted and a crytic AAAA-BBBB style identifier (which I can presume was
the original label name).

How can there be two volume labels to the same sdcard in Android?
<https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-02 17:29, Frank Slootweg wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 02.02.2025 15:50, Carlos E.R. wrote:

[...]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

To be clear, Android's native filesystem is not FAT (but ext4), but if you use a (Micro)SD-card in an Android device (which is partly the
subject of this ... ahem ... 'thread'), then the filesystem on that card
is FAT (assuming it's not used as an extension of Internal Storage
('disk' space)).

Are you sure it is ext4?

Not really sure, but that's the most common answer when you do a
Google search. I found it strange that the Wikipedia page on Android
doesn't seem to mention its native filesystem. I've seen an official
reference about which filesystems it supports [1], but not which one it
uses.

So if someone has an official reference as to which filesystem
Android uses, i.e. its native filesystem, that would be nice.

On old phones, when connected to computer, the internal storage was
taken over directly by the computer, and it did appear to be FAT.

I think that was a virtual filesystem layer, i.e. presenting the
native filesystem as an FAT filesystem, so that could be accessed by the outside world, because the outside world, especially Windows, could not generally handle anything other than FAT.

[1] <https://source.android.com/docs/core/architecture/android-kernel-file-system-support>
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-04 11:01, Marion wrote:

On Mon, 3 Feb 2025 15:14:13 +0100, Carlos E.R. wrote :

Huh, the filemanager I use is Ghost Commander. Sorry, I can't find the
official name. Setup/Aplications does not list it, Play Store does not
list it, but I have just run it. Unless it has been renamed to Total
Commander.

Google finds a site:

https://sites.google.com/site/ghostcommander1/About

but I don't know if this site is faked.

Hi Carlos,

As you're aware, I've tested all the free Android file managers, such that I-a have both Total Commander & Ghost Commander installed. As I recall, Christian Ghisler wrote the former while the latter is open source stuff.

Since I scrape the Google Play Store repository anonymously (without
logging in) I can see that Total Commander still exists in the repo. <https://play.google.com/store/apps/details? id=com.ghisler.android.TotalCommander>

However, I do see that the Google Play version of Ghost Commander is gone. <https://play.google.com/store/apps/details?id=com.ghostsq.commander>

But you can see from my screenshots I have Ghost Commander installed.
It sees *both* the Volume Name Windows formatted, plus the cryptic name. <https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

BTW, my version of Ghost Commander is v1.62.3 and when I click on the Help from inside of that app, it takes me to that URL so it's legitimate. <https://sites.google.com/site/ghostcommander1/>

I wondered, because it is full of things about the war in Ukraine.
Photos of the app are gone.

That same help inside the app says the source code is located here: <https://sourceforge.net/projects/ghostcommander/>

At that sourceforge site is a green "DOWNLOAD" button which goes to <https://sourceforge.net/projects/ghostcommander/files/latest/download>

That seemed to work when I tested it just now from Windows: <https://phoenixnap.dl.sourceforge.net/project/ghostcommander/Betas/ Ghost%20Commander%201.64.1b2.apk>
Name: Ghost Commander 1.64.1b2.apk
Size: 5005025 bytes (4887 KiB)
SHA256: B574F966938A74B9EBF9210E803DBF0856087C65DEF5E63543A120BC3A28B7B5

What I do NOT understand is why I see *both* the 0000-0001 that Windows formatted and a crytic AAAA-BBBB style identifier (which I can presume was the original label name).

No, that's probably the UUID.

How can there be two volume labels to the same sdcard in Android? <https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-02-03 14:09, Kenny McCormack wrote:

In article <m0br40Ff8v9U2@mid.individual.net>,
Arno Welzel <usenet@arnowelzel.de> wrote:
...

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not
different to that of SD cards.

Chill out, man.

People often use terminology in idiosyncratic ways. That doesn't make them wrong. I understand Carlo's frame of reference, and I accept it. You should do likewise.

Just for one example:
In some circles, unless it is a 4 footed mammal, it is not an "animal".

I assume Carlo's use of terminology is similar.

This minute, I do not know how to name SSDs. I'm confused.

To avoid this kind of senseless non-discussions, I tend to call things
as they are normally called, not by their technology. AFAIC, using the
term "flash card"/"flash media" is outdated and ambiguous terminology.

So SSD, (Micro)SD-card, USB memory-stick (not just USB stick, as there
are other type of USB sticks), etc.. If needed, add the capacity or/and
subtype (i.e. SD, SDHC, SDXC, SDUC). 'Problem' solved.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Tue, 4 Feb 2025 13:22:53 +0100, Carlos E.R. wrote :

BTW, my version of Ghost Commander is v1.62.3 and when I click on the Help >> from inside of that app, it takes me to that URL so it's legitimate.
<https://sites.google.com/site/ghostcommander1/>

I wondered, because it is full of things about the war in Ukraine.
Photos of the app are gone.

Hi Carlos,

Yes, I agree. It's funny looking. Both the URL & that political web page.

But you don't even need that page since the Sourceforge link has the APK.
<https://sourceforge.net/projects/ghostcommander/files/latest/download>

What I do NOT understand is why I see *both* the 0000-0001 that Windows
formatted and a crytic AAAA-BBBB style identifier (which I can presume was >> the original label name).

No, that's probably the UUID.

Well, I have no idea what it is, but looking up the format of a UUID, apparently the Universally Unique Identifier is a 128-bit number.

UUIDs are typically displayed as a 36-character string, divided into five sections separated by hyphens, e.g., f43ca10b-68dc-4372-d567-0b02f2a3d48f

Maybe it's a shortened UUID, but it looks suspiciously like a default
volume name (aka volume label); but I didn't write down the original name.

The question would be how to list out the UUID on Android or Windows?

How can there be two volume labels to the same sdcard in Android?
<https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

Googling, it seems sdcards don't have UUIDs anyway as they have the Card Identification (CID) register (which we've discussed prior in this thread).

That CID register is a 128-bit code includes the card serial number, manufacturer ID, and manufacturing date (plus a checksum).

CID Structure (128 bits total)
Manufacturer ID (MID): 8 bits - (e.g., SanDisk, Kingston)
OEM/Application ID (OID): 16 bits - OEM or application
Product Name (PNM): 5-character ASCII string for the product name
Product Revision (PRV): 8 bits for the product revision number
Product Serial Number (PSN): 32 bits - A unique serial number
Manufacturing Date (MDT): 12 bits - year & month of manufacture
CRC7 checksum: 7 bits - Used for error detection

Here is an example CID in hex that I found by searching for data.
03 53 44 53 55 30 34 47 10 0B 75 BC D0 23 8A

Here is what that manually translates into:
Manufacturer: SanDisk (MID: 0x03)
OEM/Application ID: SD (OID: 0x5344)
Product Name: SU04G (PNM: 0x5355303447)
Product Revision: 1.0 (PRV: 0x10)
Serial Number: 12345678 (PSN: 0x0B75BCD0)
Manufacturing Date: August 2023 (MDT: 0x238)
CRC7 Checksum: 10 in decimal (CRC: 0X67)

I think the number shown by Android is sufficiently different so as not to likely be the CID, but more likely to be the original Volume Label instead.

The problem is two fold, of course, in UNDERSTANDING what is going on.
a. Why didn't Windows sufficiently wipe out the old volume name?
b. Why do some Android apps display one, or the other, or both names?

Luckily, the $EDITORS on Android don't seem to have a problem using the Windows-assigned volume name (aka volume label); but it's an enigma.

The enigma to resolve is nobody (yet) seems to know how Windows works in
terms of changing the volume name (aka volume label), least of all me; likewise, with Android that nobody (yet) knows why this is happening, least
of all me. I hate when I don't understand something. That irks me a lot.

But it's likely there isn't an expert on this newsgroup who knows why.

I'll ask on the forums why Android file managers display two volume names.
<https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

Thanks for your help (and for the help of others who valiantly tried).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Tue, 4 Feb 2025 00:24:32 -0500, Paul wrote:

If an MBR has four partitions on it (as in MSDOS partitioning),
then the Windows mounter will mount all four partitions (as long as they
are Windows types, or, an IFS is installed in the OS to extend the capability). It's not clear, if a partition becomes un-selectable,
whether a "letter" can be assigned to a partition.
In some cases, even a RAW partition can have a letter assigned, but if
you do that and then access the letter in Windows, it will immediately request that you format the partition.

There seems to be no clear distinction in Windows between the block device/partition and the filesystem volume.

In Linux, devices and partitions have device names, but accessing the
mounted volume is done via the mount point, which is the directory where
the volume is mounted.

The important point being the two names need have nothing to do with each other. And the device name remains valid for access whether the volume is mounted or not.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

In article <vnu1go$219s9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Tue, 4 Feb 2025 00:24:32 -0500, Paul wrote:

If an MBR has four partitions on it (as in MSDOS partitioning),
then the Windows mounter will mount all four partitions (as long as they
are Windows types, or, an IFS is installed in the OS to extend the
capability). It's not clear, if a partition becomes un-selectable,
whether a "letter" can be assigned to a partition.
In some cases, even a RAW partition can have a letter assigned, but if
you do that and then access the letter in Windows, it will immediately
request that you format the partition.

There seems to be no clear distinction in Windows between the block >device/partition and the filesystem volume.

Actually, underneath the hood, Windows does have the same sort of setup as Linux does. It is all just carefully hidden away from the user, under the guise of everything being a drive letter.

But (in current - i.e., 21st century) versions of Windows, drive letters
are pretty much a fabrication.
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Pedantic
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-04 20:51, Marion wrote:

On Tue, 4 Feb 2025 13:22:53 +0100, Carlos E.R. wrote :

BTW, my version of Ghost Commander is v1.62.3 and when I click on the
Help
from inside of that app, it takes me to that URL so it's legitimate.
<https://sites.google.com/site/ghostcommander1/>

I wondered, because it is full of things about the war in Ukraine.
Photos of the app are gone.

Hi Carlos,

Yes, I agree. It's funny looking. Both the URL & that political web page.

But you don't even need that page since the Sourceforge link has the APK. <https://sourceforge.net/projects/ghostcommander/files/latest/download>

What I do NOT understand is why I see *both* the 0000-0001 that Windows
formatted and a crytic AAAA-BBBB style identifier (which I can
presume was
the original label name).

No, that's probably the UUID.

Well, I have no idea what it is, but looking up the format of a UUID, apparently the Universally Unique Identifier is a 128-bit number.

-2A UUID (Universally Unique Identifier) is a 128-bit number for a file system that is unique on both the local system and across other systems. It is randomly generated with system hardware information and time stamps as part of its seed.-+

<https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-uuid.html>

BUT, Windows often creates them much smaller

UUIDs are typically displayed as a 36-character string, divided into five sections separated by hyphens, e.g., f43ca10b-68dc-4372-d567-0b02f2a3d48f

Maybe it's a shortened UUID, but it looks suspiciously like a default
volume name (aka volume label); but I didn't write down the original name.

Yes.

The question would be how to list out the UUID on Android or Windows?

Dunno, but "good" partition software should display it.

How can there be two volume labels to the same sdcard in Android?
<https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

Googling, it seems sdcards don't have UUIDs anyway as they have the Card Identification (CID) register (which we've discussed prior in this thread).

They do have uuid, it is part of the filesystem definition.

I have just inserted an USB stick with mp3 files, and I get this info:

Telcontar:~ # l /dev/disk/by-label/ | grep sde
lrwxrwxrwx 1 root root 10 Feb 4 21:09 CORSA_3 -> ../../sde1
Telcontar:~ # l /dev/disk/by-uuid/ | grep sde
lrwxrwxrwx 1 root root 10 Feb 4 21:09 0012-D687 -> ../../sde1
Telcontar:~ #


That uuid probably comes from the manufacturer, mine would be much longer.

I can try a photo card later, I have to go out now.

[...]

Let's look at another stick with 3 partitions:

Telcontar:~ # l /dev/disk/by-label/ | grep sde
lrwxrwxrwx 1 root root 10 Feb 4 22:32 BOOT -> ../../sde2
lrwxrwxrwx 1 root root 10 Feb 4 22:32 cow -> ../../sde3
lrwxrwxrwx 1 root root 10 Feb 4 22:32 openSUSE_Leap_15.5_Rescue_CD -> ../../sde1
Telcontar:~ #


Telcontar:~ # l /dev/disk/by-uuid/ | grep sde
lrwxrwxrwx 1 root root 10 Feb 4 22:32 16b287b0-7acb-4de1-8c5c-31e9c00e34dd -> ../../sde3
lrwxrwxrwx 1 root root 10 Feb 4 22:32 2023-05-13-10-55-37-00 -> ../../sde1 lrwxrwxrwx 1 root root 10 Feb 4 22:32 AD92-FD47 -> ../../sde2
Telcontar:~ #


An storage card from my camera (formatted by the camera itself):

Telcontar:~ # l /dev/disk/by-label/ | grep sdf
lrwxrwxrwx 1 root root 10 Feb 4 22:34 LUMIX -> ../../sdf1
Telcontar:~ # l /dev/disk/by-uuid/ | grep sdf
lrwxrwxrwx 1 root root 10 Feb 4 22:34 ED50-11FC -> ../../sdf1
Telcontar:~ #


Now look at the information given by lsblk, which is very exhaustive (long lines, wrap disabled):

Telcontar:~ # lsblk --output NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,MOUNTPOINT,UUID,PARTUUID,WWN,VENDOR,MODEL,SERIAL,REV,ZONED,ALIGNMENT /dev/sdf
NAME KNAME RA RM RO PARTFLAGS SIZE TYPE FSTYPE LABEL PARTLABEL PTTYPE MOUNTPOINT UUID PARTUUID WWN VENDOR MODEL SERIAL REV ZONED ALIGNMENT
sdf sdf 512 1 0 59.5G disk dos Generic STORAGE DEVICE 000000082 TS26 none 0
rooroCsdf1 sdf1 512 1 0 59.5G part exfat LUMIX dos ED50-11FC none 0
Telcontar:~ #


This is the list of available fields:

Available output columns:
NAME device name
KNAME internal kernel device name
PATH path to the device node
MAJ:MIN major:minor device number
FSAVAIL filesystem size available
FSSIZE filesystem size
FSTYPE filesystem type
FSUSED filesystem size used
FSUSE% filesystem use percentage
FSROOTS mounted filesystem roots
FSVER filesystem version
MOUNTPOINT where the device is mounted
MOUNTPOINTS all locations where device is mounted
LABEL filesystem LABEL
UUID filesystem UUID
PTUUID partition table identifier (usually UUID)
PTTYPE partition table type
PARTTYPE partition type code or UUID
PARTTYPENAME partition type name
PARTLABEL partition LABEL
PARTUUID partition UUID
PARTFLAGS partition flags
RA read-ahead of the device
RO read-only device
RM removable device
HOTPLUG removable or hotplug device (usb, pcmcia, ...)
MODEL device identifier
SERIAL disk serial number
SIZE size of the device
STATE state of the device
OWNER user name
GROUP group name
MODE device node permissions
ALIGNMENT alignment offset
MIN-IO minimum I/O size
OPT-IO optimal I/O size
PHY-SEC physical sector size
LOG-SEC logical sector size
ROTA rotational device
SCHED I/O scheduler name
RQ-SIZE request queue size
TYPE device type
DISC-ALN discard alignment offset
DISC-GRAN discard granularity
DISC-MAX discard max bytes
DISC-ZERO discard zeroes data
WSAME write same max bytes
WWN unique storage identifier
RAND adds randomness
PKNAME internal parent kernel device name
HCTL Host:Channel:Target:Lun for SCSI
TRAN device transport type
SUBSYSTEMS de-duplicated chain of subsystems
REV device revision
VENDOR device vendor
ZONED zone model
DAX dax-capable device

For more details see lsblk(8).





Or, we can look at the fdisk output:

Telcontar:~ # fdisk -l /dev/sdf
Disk /dev/sdf: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000 <========

Device Boot Start End Sectors Size Id Type
/dev/sdf1 32768 124735487 124702720 59.5G 7 HPFS/NTFS/exFAT
Telcontar:~ #


Those are all the identifiers I know about. I can not obtain the "smart" information, if it exists, because "/dev/sdf: Unknown USB bridge [0x8564:0x4000 (0x026)]"

That CID register is a 128-bit code includes the card serial number, manufacturer ID, and manufacturing date (plus a checksum).

I don't know about that, but you can see in the output from lsblk a vendor, model, serial, and revision (it is in fact a Sandisk card, but the card reader could be interfering.

CID Structure (128 bits total)
Manufacturer ID (MID): 8 bits - (e.g., SanDisk, Kingston)
OEM/Application ID (OID): 16 bits - OEM or application
Product Name (PNM): 5-character ASCII string for the product name
Product Revision (PRV): 8 bits for the product revision number
Product Serial Number (PSN): 32 bits - A unique serial number
Manufacturing Date (MDT): 12 bits - year & month of manufacture
CRC7 checksum: 7 bits - Used for error detection

Here is an example CID in hex that I found by searching for data.
03 53 44 53 55 30 34 47 10 0B 75 BC D0 23 8A

Here is what that manually translates into:
Manufacturer: SanDisk (MID: 0x03)
OEM/Application ID: SD (OID: 0x5344)
Product Name: SU04G (PNM: 0x5355303447)
Product Revision: 1.0 (PRV: 0x10)
Serial Number: 12345678 (PSN: 0x0B75BCD0)
Manufacturing Date: August 2023 (MDT: 0x238)
CRC7 Checksum:-a 10 in decimal (CRC: 0X67)

I think the number shown by Android is sufficiently different so as not to likely be the CID, but more likely to be the original Volume Label instead.

No, they show the uuid.

The problem is two fold, of course, in UNDERSTANDING what is going on.
a. Why didn't Windows sufficiently wipe out the old volume name?
b. Why do some Android apps display one, or the other, or both names?

Each time you format, a new uuid is generated. For some reason, Windows creates a short one, and it is possibly the same as the label.

Google says:

Windows device: Open an administrator command prompt. Enter the following command: wmic path win32_computersystemproduct get UUID. The UUID for the device will now be displayed.Aug 29, 2024

How to find a device UUID - Splashtop Business - Support
Splashtop
https://support-splashtopbusiness.splashtop.com rC| articles


I suspect this is not it. That is "computer uuid".

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.

Luckily, the $EDITORS on Android don't seem to have a problem using the Windows-assigned volume name (aka volume label); but it's an enigma.

The enigma to resolve is nobody (yet) seems to know how Windows works in terms of changing the volume name (aka volume label), least of all me; likewise, with Android that nobody (yet) knows why this is happening, least of all me. I hate when I don't understand something. That irks me a lot.

The "label" command should be able to change the volume label.

But it's likely there isn't an expert on this newsgroup who knows why.

I'll ask on the forums why Android file managers display two volume names. <https://i.postimg.cc/v8z1hhKn/ghostcommander.jpg>

Apparently, some filemanagers "mount" using the label and others do using the uuid (and that would be the reason for having short uuids in Windows). Why they need to mount I don't understand, it should be the OS task.

Another possibility would be that Android mounts using both the label and the uuid, and the filemanager choose which to use.

Thanks for your help (and for the help of others who valiantly tried).

Welcome.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 15:16:42 +0100, Carlos E.R. wrote :

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

To be clear, Android's native filesystem is not FAT (but ext4), but if
you use a (Micro)SD-card in an Android device (which is partly the
subject of this ... ahem ... 'thread'), then the filesystem on that card
is FAT (assuming it's not used as an extension of Internal Storage
('disk' space)).

Are you sure it is ext4?

On old phones, when connected to computer, the internal storage was
taken over directly by the computer, and it did appear to be FAT.

I just looked it up, and I'm more confused after doing so than before.
<https://developer.android.com/training/data-storage>

The section on Data and file storage doesn't explicitly state "the" native Android file system, it implies that ext4 and f2fs are core to the system
due to their use in internal storage and system partitions.

That sounded good until I found descriptions of the kernel code, which ultimately dictates file system support but it requires technical expertise
to make sense of - which I don't have.
<https://www.google.com/search?q=https://source.android.com/docs/core/architecture/filesystems>

It seems maybe perhaps Android uses different file systems for different purposes (i.e., perhaps for system, data, cache, or external storage)???

I'm more confused now than before I looked it up, so if anyone can make
sense of those two references, please let the rest of us in on the secret.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 03.02.2025 20:00, candycanearter07 wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote at 15:04 this Sunday (GMT):

On 02.02.2025 15:50, Carlos E.R. wrote:

[snip]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

It's hard to stop momentum, sometimes. Windows refusing to switch to a different FS for external medium also doesn't help.

Given MS's FAT history I recall that I had been impressed about
MS's NTFS concept back these days. (It won't compare with ZFS or
other things we got, but for Windows standards it was very good.
I think they had borrowed concepts of NTFS from other vendors.)
WRT external media, that you focus on, there's yet more issues
than the file system; when I wanted some external file storage
system I recall I had bad experiences with the primitive (slow)
protocols regularly used between the device and the computer
(of course speaking about consumer-grade system configurations,
not professional ones).

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Tue, 2/4/2025 8:24 PM, Janis Papanagnou wrote:

On 03.02.2025 20:00, candycanearter07 wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote at 15:04 this Sunday (GMT):

On 02.02.2025 15:50, Carlos E.R. wrote:

[snip]

Android is *nix based, yes, but uses an MsDOS filesystem (FAT).

Yes, I know. For some reasons inferiors concepts are invented and
they also don't die once they've got widely spread.

It's hard to stop momentum, sometimes. Windows refusing to switch to a
different FS for external medium also doesn't help.

Given MS's FAT history I recall that I had been impressed about
MS's NTFS concept back these days. (It won't compare with ZFS or
other things we got, but for Windows standards it was very good.
I think they had borrowed concepts of NTFS from other vendors.)
WRT external media, that you focus on, there's yet more issues
than the file system; when I wanted some external file storage
system I recall I had bad experiences with the primitive (slow)
protocols regularly used between the device and the computer
(of course speaking about consumer-grade system configurations,
not professional ones).

Janis

If you're referring to protocols such as MTP (Media Transfer Protocol),
that's an architectural disaster. Yes, it's slow. Nobody should be
hobbling electronics with crap like that! This should have been
"killed with fire" long ago.

Other things work reasonably well. I don't know what the
current worlds record is for USB4 Mass Storage, but it should
be pretty good.

This is a test of a USB4 enclosure with a PCIe Rev3 x4 flash device bolted inside.

https://www.tomshardware.com/news/zikedrive-usb4-ssd-benchmarked

"When we tested an Orico M2V01-C4 USB 4 enclosure with a WD Black SN850X PCIe 4.0 SSD
inside, we got sequential read rates of 3154 MB/s and writes of 2835 MB/s
on CrystalDiskMark." ... ASMedia ASM2464PD

I don't know anything about USB4, and as it turns out, how these
particular things work is a LOT more complicated than you would think.

Performance analysis is fraught with the details.

One controller does PCIe tunneling, another controller is some sort of "more native" kind
which allows even higher rates (can get more than 4GB/sec).

https://superuser.com/questions/1764813/what-is-the-usb-4-0-theoretical-maximum-data-bandwidth-rate

Glib comments about the PHY, hardly matter at all, when the
controller type clamps down on the rate (tunneling versus native).
If someone tells you their USB4 is 80GB/sec, just snicker at them,
because they will hardly ever be able to prove that. But at least
the latest technology is slightly faster than USB3.2 2x2 2GB/sec.

If you transfer nothing but small files (like one million 4KB files)
over that USB4, you'll be lucky to get 40MB/sec. Some things, never change.
The sparkling rates, are only for HDTune or gnome-disks benchmark cases.

And when USB3.2 2x2 was all the rage ("SS20"), all three of my motherboards here, the USB-C connector is "SS10" only (1GB/sec or so).

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Tue, 4 Feb 2025 22:06:42 -0500, Paul wrote:

If you're referring to protocols such as MTP (Media Transfer Protocol), that's an architectural disaster. Yes, it's slow. Nobody should be
hobbling electronics with crap like that! This should have been "killed
with fire" long ago.

What else is there?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 02:24:01 +0100, Janis Papanagnou wrote:

Given MS's FAT history I recall that I had been impressed about MS's
NTFS concept back these days.

ItrCOs bad at dealing with lots of small files. Also itrCOs too monolithically integrated into the Windows kernel. Windows lacks a Linux-style generic
VFS layer that can support a mix of different filesystems; everything is
too heavily centred around the specific capabilities of NTFS.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Tue, 2/4/2025 11:43 PM, Lawrence D'Oliveiro wrote:

On Wed, 5 Feb 2025 02:24:01 +0100, Janis Papanagnou wrote:

Given MS's FAT history I recall that I had been impressed about MS's
NTFS concept back these days.

ItrCOs bad at dealing with lots of small files. Also itrCOs too monolithically
integrated into the Windows kernel. Windows lacks a Linux-style generic
VFS layer that can support a mix of different filesystems; everything is
too heavily centred around the specific capabilities of NTFS.

The equivalent of Linux FUSE, is Windows IFS.

One of the first popular instances, was EXT2IFS which I had installed on WinXP.

IFS stands for Installable File System. Today, brave people "do it with Dokan". The problem being, there is usually a version dependency.

Windows has *lots* of features. Remember: 7000 developers work there.
It takes fifty sheets of typing paper, to explain the permissions system.

If you want impressive, look at WSL/WSL2/WSLg . From when the first GUI showed up (it was a bit glitchy) until it was running like today, took... one week. This means they've hired some good people there. The graphics stack
is as tall as a mountain (it uses Terminal Services and "it doesn't even flash").

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Kenny McCormack, 2025-02-03 14:09:

In article <m0br40Ff8v9U2@mid.individual.net>,
Arno Welzel <usenet@arnowelzel.de> wrote:
...

I don't call an SSD a flash media.

Why not? SSD *is* flash storage. Just because there is a controller
which takes care of wear leveling, the storage technology itself is not
different to that of SD cards.

Chill out, man.

People often use terminology in idiosyncratic ways. That doesn't make them wrong. I understand Carlo's frame of reference, and I accept it. You
should do likewise.

I was just not sure, if Carlo thinks, that SSD is not flash media but
something different - and that's the reason why it is called "solid
state disk" and not "flash media disk".

JFTR: In the past there were in fact SSDs based on RAM chips with
battery backup - for example the "memory cards" of some pocket computers
or programmable calculators.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Newyana2, 2025-02-03 21:15:

On 2/3/2025 8:34 AM, Carlos E.R. wrote:

This minute, I do not know how to name SSDs. I'm confused.

Lawrence just spends his days trying to one-up other people,
especially with tech trivia. Why do you let him?

SSD is unambiguous. Like you, I
don't call it a flash drive. I don't call anything flash. There
are USB sticks, SSDs and SD cards. The type of data strorage
they use is not a practical concern. Those terms are specific
in terms of IDing the item.

Well - it was not about not calling SSD "flash media". The origin of
this discussion was this sentence by Carlos:

"Also I *never* edit a file residing in flash storage."

And "flash storage" or "flash memory" is the name for a storage
technology. SSD is "flash storage" as well as USB sticks or SD cards,
because all these media use the same basic technology, just with
different detail implementations like wear leveling etc..

Also see: <https://en.wikipedia.org/wiki/Flash_memory> and the sources
referred there.

Of course you can always decide to only call an SD card "flash media"
and anything else working with the same technology "SSD" and "USB stick" depending on what you use exactly. But using technical terms this way
makes any discussion about technology quite difficoult - because then
you always need to know, that a person understands as "flash media". One
might see only SD cards as "flash media" while another one would call a
USB stick as "flash media".
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used
it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-05 10:30, Arno Welzel wrote:

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used
it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.

<https://sachachua.com/blog/2025/01/editing-videos-with-emacs-and-subed-record-el/>

Editing videos with Emacs and subed-record.el
Jan 1, 2025| emacs, subed, video


<https://www.reddit.com/r/emacs/comments/2iqqaj/gneve_gnu_emacs_video_editor/>

GNEVE - GNU Emacs Video Editor


<https://www.youtube.com/watch?v=0vumR5Hcz7s>

GNEVE - GNU Emacs Video Editor mode demo


<https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01728.html>

GNU Emacs: A multimedia editor


GitHub
https://github.com rC| emacsattic rC| gneve
emacsattic/gneve: GNU Emacs video editor mode for ...
GNU Emacs video editor mode for editing video Edit Decision List or EDL
- emacsattic/gneve.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Carlos E.R., 2025-02-05 11:31:

On 2025-02-05 10:30, Arno Welzel wrote:

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used >>> it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.

<https://sachachua.com/blog/2025/01/editing-videos-with-emacs-and-subed-record-el/>

Editing videos with Emacs and subed-record.el
Jan 1, 2025| emacs, subed, video

<https://www.reddit.com/r/emacs/comments/2iqqaj/gneve_gnu_emacs_video_editor/>

GNEVE - GNU Emacs Video Editor

It may be called this, but Emacs is not used to *edit* the video itself
but only to control other programs.

<https://www.youtube.com/watch?v=0vumR5Hcz7s>

GNEVE - GNU Emacs Video Editor mode demo

As you can see - you still input *text* in Emacs and this will trigger
*other* programs to do things.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-05 14:27, Arno Welzel wrote:

Carlos E.R., 2025-02-05 11:31:

On 2025-02-05 10:30, Arno Welzel wrote:

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used >>>> it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.

<https://sachachua.com/blog/2025/01/editing-videos-with-emacs-and-subed-record-el/>

Editing videos with Emacs and subed-record.el
Jan 1, 2025| emacs, subed, video


<https://www.reddit.com/r/emacs/comments/2iqqaj/gneve_gnu_emacs_video_editor/>

GNEVE - GNU Emacs Video Editor

It may be called this, but Emacs is not used to *edit* the video itself
but only to control other programs.

<https://www.youtube.com/watch?v=0vumR5Hcz7s>

GNEVE - GNU Emacs Video Editor mode demo

As you can see - you still input *text* in Emacs and this will trigger *other* programs to do things.

<https://www.gnu.org/software/emacs/manual/html_node/emacs/Editing-Binary-Files.html>

44 Editing Binary Files -|

There is a special major mode for editing binary files: Hexl mode. To
use it, use M-x hexl-find-file instead of C-x C-f to visit the file.
This command converts the filerCOs contents to hexadecimal and lets you
edit the translation. When you save the file, it is converted
automatically back to binary.

You can also use M-x hexl-mode to translate an existing buffer into hex.
This is useful if you visit a file normally and then discover it is a
binary file.

Inserting text always overwrites in Hexl mode. This is to reduce the
risk of accidentally spoiling the alignment of data in the file.
Ordinary text characters insert themselves (i.e., overwrite with
themselves). There are commands for insertion of special characters by
their code. Most cursor motion keys, as well as C-x C-s, are bound in
Hexl mode to commands that produce the same effect. Here is a list of
other important commands special to Hexl mode:

C-M-d

Insert a byte with a code typed in decimal.
C-M-o

Insert a byte with a code typed in octal.
C-M-x

Insert a byte with a code typed in hex.
C-M-a

Move to the beginning of a 512-byte page.
C-M-e

Move to the end of a 512-byte page.
C-x [

Move to the beginning of a 1k-byte page.
C-x ]

Move to the end of a 1k-byte page.
M-g

Move to an address specified in hex.
M-j

Move to an address specified in decimal.
C-c C-c

Leave Hexl mode, going back to the major mode this buffer had
before you invoked hexl-mode.

Other Hexl commands let you insert strings (sequences) of binary bytes,
move by shorts or ints, etc.; type C-h a hexl- TAB for details.

Hexl mode can also be used for editing text files. This could come in
handy if the text file includes unusual characters or uses unusual
encoding (see Coding Systems). For this purpose, Hexl commands that
insert bytes can also insert ASCII and non-ASCII characters, including multibyte characters. To edit a text file with Hexl, visit the file as
usual, and then type M-x hexl-mode RET to switch to Hexl mode. You can
now insert text characters by typing them. However, inserting multibyte characters requires special care, to avoid the danger of creating
invalid multibyte sequences: you should start typing such characters
when point is on the first byte of a multibyte sequence in the file.
--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2/5/2025 4:25 AM, Arno Welzel wrote:

Well - it was not about not calling SSD "flash media". The origin of
this discussion was this sentence by Carlos:

"Also I *never* edit a file residing in flash storage."

And you didn't know he was talking about an external
stick or card? Lawrence was just trying to catch him in
"I know and you don't. Ha ha!"

It's getting to be ridiculous how many posts here are just
bickering that's kept going by compulsive arguers.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 05.02.2025 05:43, Lawrence D'Oliveiro wrote:

On Wed, 5 Feb 2025 02:24:01 +0100, Janis Papanagnou wrote:

Given MS's FAT history I recall that I had been impressed about MS's
NTFS concept back these days.

ItrCOs bad at dealing with lots of small files.

Maybe. I compared it just in the context of what was there before
in these more primitive OSes. And it *had* handling of small files
as feature at least, as opposed to these previous primitive file
systems we spoke about.

Also itrCOs too monolithically integrated into the Windows kernel.

I seem to recall to have read about it in an article before it got
released or integrated in Windows...

Windows lacks a Linux-style generic
VFS layer that can support a mix of different filesystems;

...and when Linux was just starting to evolve.

everything is
too heavily centred around the specific capabilities of NTFS.

Can't tell. Windows and NTFS were never of practical concern to me.

(In my own primary system I use more than one file system type and
these are contemporary ones.)

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 05.02.2025 08:10, Paul wrote:

IFS stands for Installable File System. [...]

Windows has *lots* of features. Remember: 7000 developers work there.
It takes fifty sheets of typing paper, to explain the permissions system.

So you want to say that it was a mis-design?

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 05.02.2025 14:27, Arno Welzel wrote:

Carlos E.R., 2025-02-05 11:31:

On 2025-02-05 10:30, Arno Welzel wrote:

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully used >>>> it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.

<[...]>
Editing videos with Emacs and subed-record.el
Jan 1, 2025| emacs, subed, video

<[...]>
GNEVE - GNU Emacs Video Editor

It may be called this, but Emacs is not used to *edit* the video itself
but only to control other programs.

<https://www.youtube.com/watch?v=0vumR5Hcz7s>

GNEVE - GNU Emacs Video Editor mode demo

As you can see - you still input *text* in Emacs and this will trigger *other* programs to do things.

I think it is indeed important to differentiate the level of editing.

Is it done in the application domain, a data type specific editor,
or a general [text] editor (that might also have extensions or be
extensible to handle "binary" data). The call of external programs
is indeed more of an IDE type of feature than to be called being an
editor for that type of application data. To me it makes no sense
to use some (bulky) editor as an IDE to invoke, say, any media file
editor; I'd just call that editor on the file(s) to be processed.

If doing specialized tasks on one (or only few) application domain
levels special purpose programs and editors may be the best way to
process them; usually you have application domain specific features
available. If you're doing general text processing where the "data
types" vary (XML, SQL, GDMO, TeX, CSV, C, etc.) but are nonetheless
_just text_ then a powerful text editor has a huge advantages.

It makes no sense to incorporate all data type specific features
in powerful general purpose editors inherently; you should not pay
for that.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote at 16:40 this Wednesday (GMT):

On 05.02.2025 08:10, Paul wrote:

IFS stands for Installable File System. [...]

Windows has *lots* of features. Remember: 7000 developers work there.
It takes fifty sheets of typing paper, to explain the permissions system.

So you want to say that it was a mis-design?

Janis

Maybe. That seems like way too much over designing for something most
people won't bother with.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:01 this Monday (GMT):

On Mon, 3 Feb 2025 19:00:02 -0000 (UTC), candycanearter07 wrote:

It's hard to stop momentum, sometimes. Windows refusing to switch to a
different FS for external medium also doesn't help.

The problems are all with the inflexibility of Windows itself. Instead of having a pluggable VFS layer that is agnostic to different filesystem formats, Linux-style, too many of its filesystem features are specifically tied to one filesystem format, namely NTFS.

Yeah, and then making the OS reliant on those systems.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 2/5/2025 1:50 PM, candycanearter07 wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:01 this Monday (GMT):

On Mon, 3 Feb 2025 19:00:02 -0000 (UTC), candycanearter07 wrote:

It's hard to stop momentum, sometimes. Windows refusing to switch to a
different FS for external medium also doesn't help.

The problems are all with the inflexibility of Windows itself. Instead of >> having a pluggable VFS layer that is agnostic to different filesystem
formats, Linux-style, too many of its filesystem features are specifically >> tied to one filesystem format, namely NTFS.

Yeah, and then making the OS reliant on those systems.

There have been cases made by Microsoft, where in the documentation
it would claim a certain thing would only work on NTFS. And then
an external dev would turn around and make it work on FAT32.

Not every one of those declarations is for real.

As for "every feature", the audience here are mostly
desktop users and not server users. The server side
has a few features we don't see here. I'm not in a position
to give an authoritative overview of every filesystem nook
and cranny.

The OS has Windows Overlay File system, and that's a technique
for saving space on a tablet (and its tiny eMMC storage).

Paul




Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2025-02-05 15:32, Newyana2 wrote:

On 2/5/2025 4:25 AM, Arno Welzel wrote:

Well - it was not about not calling SSD "flash media". The origin of
this discussion was this sentence by Carlos:

"Also I *never* edit a file residing in flash storage."

-a And you didn't know he was talking about an external
stick or card? Lawrence was just trying to catch him in
-a"I know and you don't. Ha ha!"

Yes, that's what I wanted to mean.

-a It's getting to be ridiculous how many posts here are just
bickering that's kept going by compulsive arguers.

--
Cheers, Carlos.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 10:30:23 +0100, Arno Welzel wrote:

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully
used it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.

It can edit files containing arbitrary binary data.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 10:18:28 +0100, Arno Welzel wrote:

... that's the reason why it is called "solid state disk" and not "flash media disk".

JFTR: In the past there were in fact SSDs based on RAM chips with
battery backup - for example the "memory cards" of some pocket computers
or programmable calculators.

But those were never called rCLsolid state disksrCY though, where they.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 17:38:23 +0100, Janis Papanagnou wrote:

On 05.02.2025 05:43, Lawrence D'Oliveiro wrote:

On Wed, 5 Feb 2025 02:24:01 +0100, Janis Papanagnou wrote:

Given MS's FAT history I recall that I had been impressed about MS's
NTFS concept back these days.

ItrCOs bad at dealing with lots of small files.

Maybe. I compared it just in the context of what was there before in
these more primitive OSes.

That was back in the 1990s.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 02:10:53 -0500, Paul wrote:

The equivalent of Linux FUSE, is Windows IFS.

One of the first popular instances, was EXT2IFS which I had installed on WinXP.

Do you have ext3 or ext4 support?

No? This IFS thing doesnrCOt seem to be used much.

If you want impressive, look at WSL/WSL2/WSLg . From when the first GUI showed up (it was a bit glitchy) until it was running like today,
took... one week. This means they've hired some good people there.

Except for the parts that donrCOt work.

<https://github.com/libffi/libffi/issues/552#issuecomment-1186123837>
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 14:26:23 -0500, Paul wrote:

There have been cases made by Microsoft, where in the documentation it
would claim a certain thing would only work on NTFS. And then an
external dev would turn around and make it work on FAT32.

HererCOs one big one: every time I point out the old rCLMicrosoft thinks 26 drive letters ought to be enough for anybodyrCY limitation, someone tries to claim that Windows lets you use mount points instead of drive letters, *nix-style. But then it turns out that mount points are an NTFS-specific feature, that donrCOt work with other filesystems.

As for "every feature", the audience here are mostly desktop users and
not server users. The server side has a few features we don't see here.

Then there are those of us that are workstation users.

Remember workstations? Think of them as rCLdesktopsrCY with rCLserverrCY features
integrated. The rCLdesktoprCY/rCLserverrCY separation was created as a marketing
stratagem by companies like Microsoft, deliberately crippling the rCLdesktoprCY capabilities so they could squeeze extra revenue out of customers wanting rCLserverrCY features. Such a distinction didnrCOt exist in the Unix world before Microsoft came along.

And it doesnrCOt exist in the Linux world today.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 2/5/2025 7:05 PM, Lawrence D'Oliveiro wrote:

On Wed, 5 Feb 2025 10:18:28 +0100, Arno Welzel wrote:

... that's the reason why it is called "solid state disk" and not "flash
media disk".

JFTR: In the past there were in fact SSDs based on RAM chips with
battery backup - for example the "memory cards" of some pocket computers
or programmable calculators.

But those were never called rCLsolid state disksrCY though, where they.

Gigabyte iRAM.

https://en.wikipedia.org/wiki/I-RAM

"The i-RAM was a PCI card-mounted, battery-backed RAM disk that behaved
and was marketed as a solid-state storage device."

Someone held a patent, which may have caused those to go away.

One other problem with those, is their SATA info (emulation of a SATA) was
a bit incomplete for some purposes. Someone took an Areca RAID card and plugged those in, and the Areca did not find the metadata palatable enough for the job. Maybe missing a serial number or something. Thus, hopes were dashed at the time, of setting a benchmark record :-)

I expect there are unemployed engineers running some home-brew ones
of those in their basement. That is about as close as poor people
will get to owning one.

Paul

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 2/5/2025 7:11 PM, Lawrence D'Oliveiro wrote:

On Wed, 5 Feb 2025 02:10:53 -0500, Paul wrote:

The equivalent of Linux FUSE, is Windows IFS.

One of the first popular instances, was EXT2IFS which I had installed on
WinXP.

Do you have ext3 or ext4 support?

No? This IFS thing doesnrCOt seem to be used much.

The person who wrote that (EXT2IFS), didn't seem interested in maintaining it forever.
It seemed more of a demo of IFS.

I don't know if source was released or not.

But you can see similar problems with Dokan. Someone will crank
out an item, his two friends use it, and nobody else wants to
test it. There are momentum problems of one sort or another,
with the concept. Maybe it has something to do with the
skill level of the customers (the audience is not
100% dev-class users). I don't know what the attack surface
is like on items like that.

I think there is at least one commercial offering, but
I don't know if the developer is rich yet :-) People do
fiddle with adding stuff to Windows, but they lack the
marketing muscle to make a real dent.

https://www.mtpdrive.com/purchase.html

And that's not in the Microsoft Store.

These offerings have likely been around for a while.

https://www.paragon-software.com/home/linuxfs-windows/

*******

wmic diskdrive list brief

To mount a partition:

wsl --mount [DiskPath] --partition [PartitionNumber]

And apparently, that gives access to an EXT4 via Windows Subsystem for Linux.

No, I'm not interested in testing that :-) If I were to
entertain such a thing, it would have to be integrated at
desktop level, not in some maze of twisty virtualized passages.
Via $$WSL, you could make that appear on your Windows Desktop.

The thing is, why go for these novelty items, when I can reach
across the room and have whatever I want ? Toys are just a
LAN address away.

*******

# Example of WSL command line options:

wsl --help

Copyright (c) Microsoft Corporation. All rights reserved.
For privacy information about this product please visit https://aka.ms/privacy.

Usage: wsl.exe [Argument] [Options...] [CommandLine]

Arguments for running Linux binaries:

If no command line is provided, wsl.exe launches the default shell.

--exec, -e <CommandLine>
Execute the specified command without using the default Linux shell.

--shell-type <standard|login|none>
Execute the specified command with the provided shell type.

--
Pass the remaining command line as-is.

Options:
--cd <Directory>
Sets the specified directory as the current working directory.
If ~ is used the Linux user's home path will be used. If the path begins
with a / character, it will be interpreted as an absolute Linux path.
Otherwise, the value must be an absolute Windows path.

--distribution, -d <DistroName>
Run the specified distribution.

--distribution-id <DistroGuid>
Run the specified distribution ID.

--user, -u <UserName>
Run as the specified user.

--system
Launches a shell for the system distribution.

Arguments for managing Windows Subsystem for Linux:

--help
Display usage information.

--debug-shell
Open a WSL2 debug shell for diagnostics purposes.

--install [Distro] [Options...]
Install a Windows Subsystem for Linux distribution.
For a list of valid distributions, use 'wsl.exe --list --online'.

Options:
--enable-wsl1
Enable WSL1 support.

--from-file <Path>
Install a distribution from a local file.

--legacy
Use the legacy distribution manifest.

--location <Location>
Set the install path for the distribution.

--name <Name>
Set the name of the distribution.

--no-distribution
Only install the required optional components, does not install a distribution.

--no-launch, -n
Do not launch the distribution after install.

--version <Version>
Specifies the version to use for the new distribution.

--web-download
Download the distribution from the internet instead of the Microsoft Store.

--manage <Distro> <Options...>
Changes distro specific options.

Options:
--move <Location>
Move the distribution to a new location.

--set-sparse, -s <true|false>
Set the vhdx of distro to be sparse, allowing disk space to be automatically reclaimed.

--set-default-user <Username>
Set the default user of the distribution.

--mount <Disk> <===
Attaches and mounts a physical or virtual disk in all WSL 2 distributions.

Options:
--vhd
Specifies that <Disk> refers to a virtual hard disk.

--bare
Attach the disk to WSL2, but don't mount it.

--name <Name>
Mount the disk using a custom name for the mountpoint.

--type <Type>
Filesystem to use when mounting a disk, if not specified defaults to ext4.

--options <Options>
Additional mount options.

--partition <Index> <===
Index of the partition to mount, if not specified defaults to the whole disk.

--set-default-version <Version>
Changes the default install version for new distributions.

--shutdown
Immediately terminates all running distributions and the WSL 2
lightweight utility virtual machine.

--status
Show the status of Windows Subsystem for Linux.

--unmount [Disk]
Unmounts and detaches a disk from all WSL2 distributions.
Unmounts and detaches all disks if called without argument.

--uninstall
Uninstalls the Windows Subsystem for Linux package from this machine.

--update
Update the Windows Subsystem for Linux package.

Options:
--pre-release
Download a pre-release version if available.

--version, -v
Display version information.

Arguments for managing distributions in Windows Subsystem for Linux:

--export <Distro> <FileName> [Options]
Exports the distribution to a tar file.
The filename can be - for stdout.

Options:
--format <Format>
Specifies the export format. Supported values: tar, tar.gz, vhd.

--import <Distro> <InstallLocation> <FileName> [Options]
Imports the specified tar file as a new distribution.
The filename can be - for stdin.

Options:
--version <Version>
Specifies the version to use for the new distribution.

--vhd
Specifies that the provided file is a .vhdx file, not a tar file.
This operation makes a copy of the .vhdx file at the specified install location.

--import-in-place <Distro> <FileName>
Imports the specified .vhdx file as a new distribution.
This virtual hard disk must be formatted with the ext4 filesystem type.

--list, -l [Options]
Lists distributions.

Options:
--all
List all distributions, including distributions that are
currently being installed or uninstalled.

--running
List only distributions that are currently running.

--quiet, -q
Only show distribution names.

--verbose, -v
Show detailed information about all distributions.

--online, -o
Displays a list of available distributions for install with 'wsl.exe --install'.

--set-default, -s <Distro>
Sets the distribution as the default.

--set-version <Distro> <Version>
Changes the version of the specified distribution.

--terminate, -t <Distro>
Terminates the specified distribution.

--unregister <Distro>
Unregisters the distribution and deletes the root filesystem.

And this is an example of a wmic output for a disk.

wmic diskdrive list brief

Caption DeviceID Model Partitions Size
Samsung SSD 870 EVO 4TB \\.\PHYSICALDRIVE0 Samsung SSD 870 EVO 4TB 6 4000784417280

wsl --mount \\.\PHYSICALDRIVE0 --partition 4

Then later in your session. Or even in your session in another
Terminal window.

cd /mnt/wsl/... <=== discretionary mount space, populated by the previous command
cd /mnt/c \
cd /mnt/d \__ Mounted "windows letters" for your session, which is how
cd /mnt/e / sessions have been offered from the beginning. /mnt/c/users/paul/Downloads
cd /home/paul # Inside the VHDX file, under the slash file system

df # Should be able to see all that is on offer.

( More at https://learn.microsoft.com/en-us/windows/wsl/wsl2-mount-disk )

Paul

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 5 Feb 2025 20:59:05 -0500, Paul wrote:

On Wed, 2/5/2025 7:11 PM, Lawrence D'Oliveiro wrote:

No? This IFS thing doesnrCOt seem to be used much.

The person who wrote that (EXT2IFS), didn't seem interested in
maintaining it forever.
It seemed more of a demo of IFS.

Was there anything that made serious use of it?

I don't know if source was released or not.

If it was, someone else could have maintained it. Open Source survives,
not on user popularity, but on contributions from an active community.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Wed, 2/5/2025 10:04 PM, Lawrence D'Oliveiro wrote:

On Wed, 5 Feb 2025 20:59:05 -0500, Paul wrote:

On Wed, 2/5/2025 7:11 PM, Lawrence D'Oliveiro wrote:

No? This IFS thing doesnrCOt seem to be used much.

The person who wrote that (EXT2IFS), didn't seem interested in
maintaining it forever.
It seemed more of a demo of IFS.

Was there anything that made serious use of it?

I don't know if source was released or not.

If it was, someone else could have maintained it. Open Source survives,
not on user popularity, but on contributions from an active community.

I'm editing a text file from an EXT4 partition, using
nothing but Microsoft-provided tools. Right now!

wmic diskdrive list brief

Caption DeviceID Model Partitions Size
Samsung SSD 870 EVO 4TB \\.\PHYSICALDRIVE0 Samsung SSD 870 EVO 4TB 6 4000784417280
WDC WD5003ABYZ-011FA0 \\.\PHYSICALDRIVE1 WDC WD5003ABYZ-011FA0 6 500105249280 <=== Disk drive
from Test Machine

wsl --mount \\.\PHYSICALDRIVE1 --partition 7

The disk was successfully mounted as '/mnt/wsl/PHYSICALDRIVE1p7'
To unmount and detach, run 'wsl.exe --unmount \\.\PHYSICALDRIVE1'

bash

df # Boring bits removed (Ubuntu-specific SNAP mounts and so on)

Filesystem 1K-blocks Used Available Use% Mounted on

none 32897176 4 32897172 1% /mnt/wsl
/dev/sdc7 40973776 7759136 31101104 20% /mnt/wsl/PHYSICALDRIVE1p7 /dev/sdd 1055762868 5272140 996787256 1% / # slash in VHDX file
none 32897176 100 32897076 1% /mnt/wslg
C:\ 124493820 84403884 40089936 68% /mnt/c
H:\ 135264344 58723016 76541328 44% /mnt/h
S:\ 715167740 675510336 39657404 95% /mnt/s

\\wsl$ in File Explorer, brings up a file share from the running bash.
Bash can also be running, without a shell instance, and serve the files
from a faceless session, until shutdown command issued.

\\wsl$ exposes:

\\wsl.localhost\Ubuntu-20.04\mnt\wsl\PHYSICALDRIVE1p7\home\bullwinkle
I-AM-LM221CIN.txt 83 bytes

Here is the accompanying picture.

[Picture]

https://i.postimg.cc/gjdTrsLx/Mount-EXT4-via-WSL-and-fileshare.gif

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Lawrence D'Oliveiro, 2025-02-06 01:05:

On Wed, 5 Feb 2025 10:18:28 +0100, Arno Welzel wrote:

... that's the reason why it is called "solid state disk" and not "flash
media disk".

JFTR: In the past there were in fact SSDs based on RAM chips with
battery backup - for example the "memory cards" of some pocket computers
or programmable calculators.

But those were never called rCLsolid state disksrCY though, where they.

Correct - "solid state drive" and not "solid state disk". However this
is by definition a drive which does not have moving parts. If this is
achieved by using battery powered RAM or flash memory is not important
for that definition.

Also see:

<https://www.techtarget.com/searchstorage/definition/RAM-based-solid-state-drive-SSD>

And Atto still offers RAM based SSDs:

<https://www.atto.com/products/silicondisk-storage-appliance/>
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Carlos E.R., 2025-02-05 14:35:

[...]

<https://www.gnu.org/software/emacs/manual/html_node/emacs/Editing-Binary-Files.html>

44 Editing Binary Files -|

There is a special major mode for editing binary files: Hexl mode. To
use it, use M-x hexl-find-file instead of C-x C-f to visit the file.
This command converts the filerCOs contents to hexadecimal and lets you
edit the translation. When you save the file, it is converted
automatically back to binary.

As I said - you still edit *text*. There is just an automatic conversion
from binary to *text* and then back to binary. But the editor itself
still works on *text*.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Lawrence D'Oliveiro, 2025-02-06 00:14:

On Wed, 5 Feb 2025 10:30:23 +0100, Arno Welzel wrote:

Lawrence D'Oliveiro, 2025-02-03 04:01:

On Sun, 2 Feb 2025 15:07:34 +0100, Carlos E.R. wrote:

Because "editor" to me is a text editor ...

Emacs is an editor, and not just a text editor. I have successfully
used it to edit non-text files.

To be more precise: it is a text editor which can be extended to
interpret the syntax of text stored in a file - like Markdown. But you
can not edit videos or bitmap graphics with it, since it is still a
*text* based editor.

It can edit files containing arbitrary binary data.

It can use extensions which convert binary data to text, then edit the
text and when saving the text it will be converted back to binary data.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:16 this Thursday (GMT):

On Wed, 5 Feb 2025 14:26:23 -0500, Paul wrote:

There have been cases made by Microsoft, where in the documentation it
would claim a certain thing would only work on NTFS. And then an
external dev would turn around and make it work on FAT32.

HererCOs one big one: every time I point out the old rCLMicrosoft thinks 26 drive letters ought to be enough for anybodyrCY limitation, someone tries to claim that Windows lets you use mount points instead of drive letters, *nix-style. But then it turns out that mount points are an NTFS-specific feature, that donrCOt work with other filesystems.

I remember them being not worth the effort to do, since you had to do it
every time you plugged in the drive. Then again, I haven't used Windows
in a while, so I might be misremembering.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Mon, 3 Feb 2025 09:42:27 -0000 (UTC), Marion wrote:

Meanwhile, the Android apps I had suggested are, um, er, shall we say
almost foolproof? All you do is pick a photo & you cartoonify it.

Takes mere seconds.
And no skills whatsoever.

Give your users one button to push, they will all push that button. And
all produce the same result.

At some point the novelty wears off. Until the product vendor comes up
with a new button for you to push.

And maybe they start charging for some of those buttons, for the users who want an effect that isnrCOt quite the same as those available on the
freeware version.

And now they have a revenue stream. And the users have gained no skills whatsoever, beyond the ability to push the offered buttons.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Thu, 6 Feb 2025 20:21:14 +0100, Arno Welzel wrote:

As I said - you still edit *text*. There is just an automatic conversion
from binary to *text* and then back to binary. But the editor itself
still works on *text*.

I have done direct editing of binary data in Emacs.
--- Synchronet 3.21b-Linux NewsLink 1.2