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

Groups > alt.comp.os.windows-10 > #181812 > unrolled thread

Clever helpful suggestion for portable memory using Windows & Android editors

Back to article view | Back to alt.comp.os.windows-10

Contents

  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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

#181879

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.

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

#181835

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 ������
> 
> 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. :)

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

#181860

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'.

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

#181862

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."

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

#181864

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!).

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

#181894

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

> [...]

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

#181922

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 

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

#181927

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
>    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.

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.

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

#181945

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>

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

#181950

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  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.

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

#181961

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).

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

#181969

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.

«A 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
└─sdf1 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:  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 › 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.

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

#181893

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

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

#181895

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.

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

#181897

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

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

#181898 — [meta] posting mistake

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

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

#181900

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)).

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

#181901 — ext4 on Android (Was: blah, blah, blah...)

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!"

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

#181917 — Re: ext4 on Android (Was: blah, blah, blah...)

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

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

#181928 — ext4 on Android (Was: blah, blah, blah...)

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.

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

Page 6 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