Question about file transfer to Android device
Bret Busby
bret at busby.net
Tue Sep 23 15:53:21 UTC 2025
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)
..............
More information about the ubuntu-users
mailing list