Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.os.windows-10 > #181812 > unrolled thread
| Started by | Marion <marion@facts.com> |
|---|---|
| First post | 2025-01-31 17:48 +0000 |
| Last post | 2025-02-02 22:54 +0000 |
| Articles | 20 on this page of 158 — 14 participants |
Back to article view | Back to alt.comp.os.windows-10
Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-01-31 17:48 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Andy Burns <usenet@andyburns.uk> - 2025-01-31 19:09 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-01-31 19:26 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-01-31 21:18 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-01-31 23:19 +0100
The "label" command (Was: Clever helpful suggestion for portable memory using Windows &) Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-01-31 22:24 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Andy Burns <usenet@andyburns.uk> - 2025-01-31 22:25 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-01-31 22:38 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-01-31 23:39 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-01-31 22:48 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Quincy the fifth <quincythefifth@telekom.net> - 2025-02-01 00:22 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-01 06:03 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Andy Burns <usenet@andyburns.uk> - 2025-02-01 10:15 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-01 18:45 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-01 18:51 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-01 14:55 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-01 19:16 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-01 20:54 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-02 03:21 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-02 14:43 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 00:01 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-03 01:59 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 03:06 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-03 13:28 +0100
What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-02-03 13:09 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-03 14:34 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors knuttle <keith_nuttle@yahoo.com> - 2025-02-03 10:47 -0500
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Newyana2 <newyana@invalid.nospam> - 2025-02-03 15:15 -0500
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-05 10:25 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Newyana2 <newyana@invalid.nospam> - 2025-02-05 09:32 -0500
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-05 20:46 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Paul <nospam@needed.invalid> - 2025-02-03 15:42 -0500
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 22:40 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-07 21:45 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Frank Slootweg <this@ddress.is.invalid> - 2025-02-04 15:41 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-05 10:18 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 00:05 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Paul <nospam@needed.invalid> - 2025-02-05 20:04 -0500
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-06 20:17 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 21:02 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-07 21:47 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 03:28 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-08 10:18 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:35 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-10 08:47 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Frank Slootweg <this@ddress.is.invalid> - 2025-02-10 10:55 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-11 01:00 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-13 19:59 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-13 22:15 +0000
[OT] Storage technology "back then" (was Re: What is an animal or an SSD drive? [...]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-14 02:10 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-18 11:56 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-18 21:55 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-21 09:12 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-21 23:35 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-25 18:27 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Frank Slootweg <this@ddress.is.invalid> - 2025-02-25 18:25 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-26 08:53 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-26 13:10 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Frank Slootweg <this@ddress.is.invalid> - 2025-02-26 15:02 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-25 20:28 +0000
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-26 08:54 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-26 08:49 +0100
Re: What is an animal or an SSD drive? (Was: blah, blah, blah) Android editors Frank Slootweg <this@ddress.is.invalid> - 2025-02-21 14:12 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-02 04:16 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-02 05:40 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-02 06:05 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-02 21:34 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 00:01 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-03 09:42 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 20:54 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-08 04:22 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-02 15:07 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-02 23:42 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-03 02:21 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 03:05 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-03 09:59 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 03:01 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-03 19:12 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-05 10:30 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-05 11:31 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-05 14:27 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-05 14:35 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-06 20:21 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 20:57 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-06 23:58 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 05:57 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-07 10:30 +0100
Editing binary data with editors - or is there no difference of text and binary? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-07 10:57 +0100
Re: Editing binary data with editors - or is there no difference of text and binary? "Carlos E.R." <robin_listas@es.invalid> - 2025-02-07 11:44 +0100
Re: Editing binary data with editors - or is there no difference of text and binary? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-07 14:39 +0100
Re: Editing binary data with editors - or is there no difference of text and binary? "Carlos E.R." <robin_listas@es.invalid> - 2025-02-07 19:39 +0100
Re: Editing binary data with editors - or is there no difference of text and binary? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 03:26 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-05 18:12 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-05 23:14 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-06 20:22 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 20:57 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Arno Welzel <usenet@arnowelzel.de> - 2025-02-07 21:50 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 03:27 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-02 03:21 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-02 15:07 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-02 03:20 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-01 05:40 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-01 16:34 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-02-01 16:29 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-01 18:10 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-02 15:44 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-03 10:40 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-03 15:14 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-04 10:01 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-04 13:22 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-04 19:51 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-04 23:12 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-02 15:24 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-02 15:50 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-02 16:04 +0100
[meta] posting mistake Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-02 16:26 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Frank Slootweg <this@ddress.is.invalid> - 2025-02-02 16:29 +0000
ext4 on Android (Was: blah, blah, blah...) gazelle@shell.xmission.com (Kenny McCormack) - 2025-02-02 16:37 +0000
Re: ext4 on Android (Was: blah, blah, blah...) Jeff Layman <Jeff@invalid.invalid> - 2025-02-03 09:14 +0000
ext4 on Android (Was: blah, blah, blah...) "Carlos E.R." <robin_listas@es.invalid> - 2025-02-03 15:16 +0100
Re: ext4 on Android (Was: blah, blah, blah...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 21:59 +0000
Re: ext4 on Android Frank Slootweg <this@ddress.is.invalid> - 2025-02-04 10:23 +0000
Re: ext4 on Android (Was: blah, blah, blah...) Marion <marion@facts.com> - 2025-02-04 22:48 +0000
Re: ext4 on Android (Was: blah, blah, blah...) "Carlos E.R." <robin_listas@es.invalid> - 2025-02-25 23:16 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 21:57 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-02-03 19:00 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 22:01 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-02-05 18:50 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Paul <nospam@needed.invalid> - 2025-02-05 14:26 -0500
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 00:16 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-02-06 20:50 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Paul <nospam@needed.invalid> - 2025-02-03 19:58 -0500
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-04 01:15 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Paul <nospam@needed.invalid> - 2025-02-04 00:24 -0500
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-04 21:40 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors gazelle@shell.xmission.com (Kenny McCormack) - 2025-02-04 22:11 +0000
External media file systems (was Re: ...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-05 02:24 +0100
Re: External media file systems (was Re: ...) Paul <nospam@needed.invalid> - 2025-02-04 22:06 -0500
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-05 04:41 +0000
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-05 04:43 +0000
Re: External media file systems (was Re: ...) Paul <nospam@needed.invalid> - 2025-02-05 02:10 -0500
Re: External media file systems (was Re: ...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-05 17:40 +0100
Re: External media file systems (was Re: ...) candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-02-05 18:50 +0000
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 00:11 +0000
Re: External media file systems (was Re: ...) Paul <nospam@needed.invalid> - 2025-02-05 20:59 -0500
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 03:04 +0000
Re: External media file systems (was Re: ...) Paul <nospam@needed.invalid> - 2025-02-05 22:48 -0500
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 21:00 +0000
Re: External media file systems (was Re: ...) Paul <nospam@needed.invalid> - 2025-02-06 16:20 -0500
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 22:42 +0000
Re: External media file systems (was Re: ...) Paul <nospam@needed.invalid> - 2025-02-07 00:44 -0500
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 06:00 +0000
Re: External media file systems (was Re: ...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-02-05 17:38 +0100
Re: External media file systems (was Re: ...) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-06 00:06 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-03 21:56 +0000
A little bit of discussion between Janis and me (Was: Stupid suggestion(s) for "portable" "memory" using Windows & Android "editors") gazelle@shell.xmission.com (Kenny McCormack) - 2025-02-02 14:53 +0000
Re: Clever helpful suggestion for portable memory using Windows & Android editors "Carlos E.R." <robin_listas@es.invalid> - 2025-02-01 20:59 +0100
Re: Clever helpful suggestion for portable memory using Windows & Android editors Marion <marion@facts.com> - 2025-02-02 22:54 +0000
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-03 21:59 +0000 |
| Subject | Re: ext4 on Android (Was: blah, blah, blah...) |
| Message-ID | <vnre8s$1fpir$3@dont-email.me> |
| In reply to | #181928 |
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. You’re thinking MTP. My old phone supports that as well. It’s a file-level protocol, so it doesn’t 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 phone’s internal storage. No Android phone is going to expose its OS installation area for any external access at the sector level.
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-02-04 10:23 +0000 |
| Subject | Re: ext4 on Android |
| Message-ID | <vnstb7.12cs.1@ID-201911.user.individual.net> |
| In reply to | #181928 |
> 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>
[toc] | [prev] | [next] | [standalone]
| From | Marion <marion@facts.com> |
|---|---|
| Date | 2025-02-04 22:48 +0000 |
| Subject | Re: ext4 on Android (Was: blah, blah, blah...) |
| Message-ID | <vnu5go$10k3$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #181928 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-02-25 23:16 +0100 |
| Subject | Re: ext4 on Android (Was: blah, blah, blah...) |
| Message-ID | <m3s19lxun3.ln2@Telcontar.valinor> |
| In reply to | #181974 |
On 2025-02-04 23:48, Marion wrote:
> 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>
This link describes features the filesystem must have, but they don't
say which filesystem they use. Thus it can be "something else".
>
> 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.
<https://source.android.com/docs/core/architecture/android-kernel-file-system-support>
says they support these:
exfat (supported in kernel 5.10 and later)
ext4
f2fs
fuse
incfs
Vfat
EROFS
I'm guessing the choice is up to the manufacturer.
--
Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-03 21:57 +0000 |
| Message-ID | <vnre3s$1fpir$2@dont-email.me> |
| In reply to | #181900 |
I’m 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.
[toc] | [prev] | [next] | [standalone]
| From | candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> |
|---|---|
| Date | 2025-02-03 19:00 +0000 |
| Message-ID | <slrnvq242k.3cd70.candycanearter07@candydeb.host.invalid> |
| In reply to | #181897 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-03 22:01 +0000 |
| Message-ID | <vnrebh$1fpir$4@dont-email.me> |
| In reply to | #181930 |
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.
[toc] | [prev] | [next] | [standalone]
| From | candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> |
|---|---|
| Date | 2025-02-05 18:50 +0000 |
| Message-ID | <slrnvq7cjr.1u0ps.candycanearter07@candydeb.host.invalid> |
| In reply to | #181938 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-02-05 14:26 -0500 |
| Message-ID | <vo0e0v$2h21c$1@dont-email.me> |
| In reply to | #182011 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-06 00:16 +0000 |
| Message-ID | <vo0v03$2k46v$4@dont-email.me> |
| In reply to | #182012 |
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. Here’s one big one: every time I point out the old “Microsoft thinks 26 drive letters ought to be enough for anybody” 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 don’t 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 “desktops” with “server” features integrated. The “desktop”/“server” separation was created as a marketing stratagem by companies like Microsoft, deliberately crippling the “desktop” capabilities so they could squeeze extra revenue out of customers wanting “server” features. Such a distinction didn’t exist in the Unix world before Microsoft came along. And it doesn’t exist in the Linux world today.
[toc] | [prev] | [next] | [standalone]
| From | candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> |
|---|---|
| Date | 2025-02-06 20:50 +0000 |
| Message-ID | <slrnvqa84m.t2vt.candycanearter07@candydeb.host.invalid> |
| In reply to | #182020 |
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. > > Here’s one big one: every time I point out the old “Microsoft thinks 26 > drive letters ought to be enough for anybody” 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 don’t 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
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-02-03 19:58 -0500 |
| Message-ID | <vnroo1$1hv2k$1@dont-email.me> |
| In reply to | #181930 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-04 01:15 +0000 |
| Message-ID | <vnrpn3$1htu1$5@dont-email.me> |
| In reply to | #181941 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-02-04 00:24 -0500 |
| Message-ID | <vns8ag$1nr16$1@dont-email.me> |
| In reply to | #181942 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-04 21:40 +0000 |
| Message-ID | <vnu1go$219s9$1@dont-email.me> |
| In reply to | #181943 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2025-02-04 22:11 +0000 |
| Message-ID | <vnu3a9$3rqlr$1@news.xmission.com> |
| In reply to | #181966 |
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
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-02-05 02:24 +0100 |
| Subject | External media file systems (was Re: ...) |
| Message-ID | <vnueji$23csf$1@dont-email.me> |
| In reply to | #181930 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-02-04 22:06 -0500 |
| Subject | Re: External media file systems (was Re: ...) |
| Message-ID | <vnukk4$247om$1@dont-email.me> |
| In reply to | #181980 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-05 04:41 +0000 |
| Subject | Re: External media file systems (was Re: ...) |
| Message-ID | <vnuq67$28lu7$1@dont-email.me> |
| In reply to | #181981 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-02-05 04:43 +0000 |
| Subject | Re: External media file systems (was Re: ...) |
| Message-ID | <vnuq90$28lu7$2@dont-email.me> |
| In reply to | #181980 |
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. It’s bad at dealing with lots of small files. Also it’s 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.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | alt.comp.os.windows-10
csiph-web