Question about file transfer to Android device
Verde Denim
tdldev at gmail.com
Tue Sep 23 15:58:06 UTC 2025
Please take this email off this thread and delete is jack has passed
On Tue, Sep 23, 2025, 11:53 AM Bret Busby <bret at busby.net> wrote:
> On 23/9/25 22:23, Colin Law wrote:
> > On Tue, 23 Sept 2025 at 14:55, Bret Busby <bret at busby.net> wrote:
> >>
> >> On 23/9/25 21:21, Colin Law wrote:
> >>> On Tue, 23 Sept 2025 at 14:08, Bret Busby <bret at busby.net> wrote:
> >>>>
> >>>> What I am complaining about, is that the file management is going to
> the
> >>>> hardware level, when I believe that it should be operating at the
> >>>> operating system level.
> >>>
> >>> What makes you say that? It isn't the file management that is
> >>> failing, it is libmtp recognising the device that is the problem. It
> >>> is the same problem that arises if a new chip is designed for wifi,
> >>> which needs modified wifi drivers. The new wifi chip will not work
> >>> with an old version of the OS. Note that the error in the log you
> >>> posted occurred when the device was plugged in, it is nothing to do
> >>> with file management.
> >>>
> >>>>
> >>>> If we use filezilla, or wget, they do not care what CPU or what brand
> >>>> and model of HDD's or whether the HDD's are mechanical or electronic,
> at
> >>>> the other end - they do their file operations, as far as I am aware,
> at
> >>>> the operating system level, and they do not care whether the network
> >>>> administrator at the other end, is wearing pantyhose or woollen socks,
> >>>> or leather soled footwear or rubber soled footwear.
> >>>
> >>> But the OS must understand the hardware of the HDD, or the wifi
> interface.
> >>>
> >>
> >> The operating system at the other end, should interface with its
> >> hardware, not the operating system that is the remote operating system.
> >>
> >> Does wget or filezilla contain all of the hardware drivers for all
> >> possible hardware components of all possible computers?
> >>
> >> The wifi interface is irrelevant.
> >>
> >> The connection was attempted via USB tethering - hardwired.
> >>
> >> An operating system should be concerned with hardware drivers only for
> >> the hardware with which it directly interfaces.
> >>
> >> When the operating system connects via communication protocols, it
> >> should not need to be concerned with hardware drivers for hardware on a
> >> remote device with which the initiating device is communicating, through
> >> its operating system, to the operating system on the remote device.
> >>
> >> The communication between the two devices, should be solely at the
> >> operating system level, unless the initiating device is attempting to
> >> perform a direct hardware operation on the remote device, like changing
> >> the processing speed of the CPU on the remote device, or, checking the
> >> HDD on the remote device, for bad blocks.
> >>
> >> File transfer operations between devices that have independent operating
> >> systems, should be dependent on only the interface between the operating
> >> systems, not, on the hardware of the remote device.
> >>
> >> If you check in at an airport, to board a flight, it should not matter,
> >> and, the carrier airline should have no need to know, what size, brand,
> >> or model, of tyres are on the vehicle that conveyed you to the airport,
> >> or, whether the driver of the vehicle that conveyed you to the airport,
> >> has false teeth or permed hair. What should matter, is that, at the
> >> airport, you follow the correct protocols for checking in, to board the
> >> flight.
> >>
> >> The need for hardware drivers for remote devices, simply for file
> >> transfer operations, when both devices have independent, standalone
> >> operating systems, is simply an obstruction to the file transfer
> >> process. The file transfer process should be solely at the operating
> >> system level, and, not at the hardware level.
> >>
> >> PC-DOS had a switch for its formatting command, that enabled a character
> >> to be written to every byte position on a HDD. For something like that,
> >> okay, the driver for the HDD, is needed. For remote file transfer
> >> operations, between independent, standalone computers, with independent,
> >> standalone operating systems, hardware drivers, and, machine level
> >> communications, should be not needed, between the devices - it should be
> >> done solely by communication between the operating systems of the
> >> devices, and, the operating system of each device, should alone, deal
> >> with the hardware communications for the device, unless, as stated
> >> above, the remote operation is a direct hardware operation, and, not
> >> simply a data transfer operation.
> >
> > So is it the mtp protocol that you are complaining about?
> >
> > Colin L.
>
> Yes.
>
> Two further things have occurred to me
>
> The first, is that, before it broke my OS (so that, until I do a
> shutdown and reboot, I do not know whether I will be able to access my
> Android 12 filesystem again), when accessing the filesystem on the
> Android 12 device, it showed the file system - not blocks and byte level
> stuff on the storage device on the device, so, that was operating system
> level, and, not hardware level.
>
> The second, is that, in considering that I have said that I used USB
> tethering, and, not wifi to connect to the Android devices, and,
> thinking about the other USB tethered devices that I have connected,m I
> have a Toshiba external USB HDD, and, a number of Samsung external USB
> SSD's.
>
>
> "
> ~ > fastfetch
> ...-:::::-... bret at bret-Precision-Tower-5810
> .-MMMMMMMMMMMMMMM-. ------------------------------
> .-MMMM`..-:::::::-..`MMMM-. OS: Linux Mint 21.3 x86_64
> .:MMMM.:MMMMMMMMMMMMMMM:.MMMM:. Host: Precision Tower 5810
> -MMM-M---MMMMMMMMMMMMMMMMMMM.MMM- Kernel: Linux
> 5.15.0-153-generic
> `:MMM:MM` :MMMM:....::-...-MMMM:MMM:` Uptime: 24 days, 3 hours,
> 57 mins
> :MMM:MMM` :MM:` `` `` `:MMM:MMM: Packages: 3565 (dpkg)
> .MMM.MMMM` :MM. -MM. .MM- `MMMM.MMM. Shell: bash 5.1.16
> :MMM:MMMM` :MM. -MM- .MM: `MMMM-MMM: Display (PHL 243V5):
> 1920x1080 in 24", 60 Hz [External]
> :MMM:MMMM` :MM. -MM- .MM: `MMMM:MMM: DE: Mate 1.26.0
> :MMM:MMMM` :MM. -MM- .MM: `MMMM-MMM: WM: Marco (X11)
> .MMM.MMMM` :MM:--:MM:--:MM: `MMMM.MMM. WM Theme: TraditionalOk
> :MMM:MMM- `-MMMMMMMMMMMM-` -MMM-MMM: Theme: gtk2 [Qt],
> TraditionalOk [GTK2/3/4]
> :MMM:MMM:` `:MMM:MMM: Icons: Mint-Y [Qt], mate
> [GTK2/3/4]
> .MMM.MMMM:--------------:MMMM.MMM. Font: Andika (14pt) [GTK2/3/4]
> '-MMMM.-MMMMMMMMMMMMMMM-.MMMM-' Cursor: mate (24px)
> '.-MMMM``--:::::--``MMMM-.' Terminal: mate-terminal 1.26.0
> '-MMMMMMMMMMMMM-' Terminal Font: Monospace
> (14pt)
> ``-:::::-`` CPU: Intel(R) Xeon(R)
> E5-2660 v4 (28) @ 3.20 GHz
> GPU: NVIDIA GeForce GTX
> 1660 SUPER [Discrete]
> Memory: 100.28 GiB / 125.71
> GiB (80%)
> Swap: 5.15 GiB / 30.52 GiB
> (17%)
> Disk (/): 24.86 GiB / 29.87
> GiB (83%) - ext4
> Disk (/home): 44.96 GiB /
> 58.44 GiB (77%) - ext4
> Disk
> (/media/bret/Samsung_T5): 706.84 GiB / 931.48 GiB (76%) - exfat
> Disk (/media/bret/T7): 3.14
> TiB / 3.64 TiB (86%) - exfat
> Disk (/media/bret/T71):
> 992.45 GiB / 3.64 TiB (27%) - exfat
> Disk (/media/bret/TOSHIBA
> EXT): 696.83 GiB / 1.82 TiB (37%) - fuseblk
> "
>
> Now, the thing here, is that I remember that, when I got my first
> Samsung T5, an issue arose, of the file format on the device.
>
> The Samsung T5 and T7 external USB SSD's use the exfat file format, as
> shown above, rather than FAT16 or FAT32 or NTFS.
>
> So, the issue of a driver for that filesystem arose. Now, whilst Debian,
> at the time, had a downloadable and installable exfat driver, to be able
> to access the filesystems in those SSD's, Ubuntu Linux incorporated the
> exfat driver, as a "native" driver.
>
> So, in accessing those SSD's, drivers were not needed, that were
> hardware dependent - separate drivers for each capacity of each of the
> T5 and T7 models, but, instead, the single driver, for the exfat file
> system, so, accessing those external, USB tethered, storage devices,
> required the single driver that is filesystem type based; software, and,
> not hardware, specific.
>
> The Android devices, whether cellphones or tablet PC's, when connected
> via USB tethering, for the purpose of file transfer operations, are,
> again, simply seen as USB storage devices, like digital cameras, and,
> so, in the case of the Android devices, it is not hardware specific
> drivers that are needed, or, should be invoked, but, instead, software
> specific - filesystem specific, drivers, that are needed, and, that
> should be invoked.
>
> So, yes, I say that a fault exists with the mtp protocol, in that,
> instead of stuffing around with hardware drivers ("There are more
> variants of hardware, Horatio, than man has ever dreamed of"), which,
> apparently, gratuitously complicate and obfuscate the process, the mtp
> protocol should be reliant on the drivers for the filesystems; via the
> operating systems, and, what should be more properly done, is that the
> protocol should first detect the operating system and version, and, the
> applicable filesystem, of the device to which connection is attempted to
> be made for file transfer, then, assess whether an applicable driver is
> present, to deal with the filesystem and operating system of the device
> to which connection is being attempted, and, then, if no appropriate
> driver is present, to display an error message, stating the operating
> system and version number, and/or filesystem name or description, and,
> stating that no appropriate driver is present, or that it is otherwise
> incompatible.
>
> So, in short, yes, I say that the mtp protocol is defective.
>
> ..
> Bret Busby
> Armadale
> West Australia
> (UTC+0800)
> ..............
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20250923/112584a0/attachment-0001.html>
More information about the ubuntu-users
mailing list