Mounting Android's File System

[John Scott]

Ahoy there, Bernie!

> IF I COPY (OR RSYNC) A FILE FROM THE LAPTOP TO THE DEVICE, THE TIMESTAMPS ARE NOT KEPT
CAN YOU TALK LOUDER? I DON'T HAVE MY GLASSES ON!!!11
This is a known defect in Android that no one has gotten around to fixing; the MTP protocol is capable: https://issuetracker.google.com/issues/36974569
It is what it is 🤷

> Some co-workers have suggested network-using alternatives (many of them non-FOSS):
> KDEconnect.kde.org

Based on the manner you stylized this, I take it you probably don't understand what KDE Connect really is. I think you'll find it's a beautiful solution to your problem (assuming it preserves timestamps; I can give it a try and report back).
• KDE Connect is *not* a centralized network service, and it need not use TCP/IP at all. Instead it works more like secure shell: it's a point-to-point connection between a workstation of yours and a mobile device of yours without "phoning home" anywhere. I understand where you get the idea that KDE Connect is a network service in the traditional sense; Mozilla Firefox synchronizes user preferences, bookmarks, and things using accounts on Mozilla servers. In this case though, KDE Connect is really just a protocol, and it's usually used on a LAN (but other transports exist, but I don't want to spoil the surprise).
• People often conflate the two, but KDE Connect also doesn't have much of anything to do with KDE *Plasma*, the desktop environment from the KDE folks. KDE Connect (on the workstation side) has a command-line client and a GNOME client too, the latter called GSConnect. In Debian, it's even available as a package. The app used on the Android mobile device is still the same KDE Connect app; they interoperate fine from speaking the same protocol.
I really suggest that you give this a try, at least eventually; it's a buttery-smooth, no-fuss, long-term solution to your problem (and other problems you didn't realize were tractable before). I must confess that I seldom use an Android device nowadays, but it would be so tragic for you to miss this opportunity, that I must evangelize it here.

> I ALSO HAVE THE DEVICE MOUNTED TO MY COMPUTER:
> $ mount | grep mnt
> jmtpfs on ~/mnt type fuse.jmtpfs (rw,nosuid,nodev,relatime,user_id=XXXXX,group_id=XXXXX)
Just as a fun fact, the "device" isn't quite mounted to your computer in the conventional sense. Here, MTP is basically an FTP, NFS, or WebDAV-like protocol over USB that's an abstraction layer above the filesystem. Fortunately, MTP is capable of conveying filestamp information (Android just botches it terribly), so this isn't a real problem. The fact that you're able to "mount" it at all is thanks to FUSE voodoo to virtualize a file system (as opposed to virtualizing a backing *device*, which there is none).

> Anybody have any ideas, please?
Here are some extra options:
• Try doing Bluetooth file transfers if your workstation has support for that. In GNOME for example, pairing the devices is easy in the system settings. Even if the file manager lacks a convenient button to initiate the transfer, it's still easy inside the GNOME Bluetooth settings to choose the mobile device you're paired to and then send a file from there.
• Another technical option I mention for the sake of completeness is using adb, the Android debugging agent, which allows a lot of advanced communication between a PC and an Android device. This includes file transfers, backups/flash dumps, and a lot of low-level bits like that. If you have time to spare (or at least gamble with) and are feeling brave or reckless this may be right for you.

P.S. You should probably remove this from your email signature:
> PGP e-mail is welcome!  Get my 1024 bit public key from:
> https://www.TheMoreIKnow.info/hoeferbe/0x1EA6025D9DFB224E69D4CE0E7241A6A9446A6F93.key

That's a 1024-bit DSA key from 2000 (before I was born), and the key signatures (and even the signature on your email) are made using SHA-1. The first SHA-1 collision was found by Google years ago, and your key and signed messages are distrusted for multiple disjoint reasons.
And with that aside, manually importing keys from URLs in email signature lines is not a good or scalable user experience. This problem has already been solved though; there are several schemes for OpenPGP keys to be discovered from a signed email alone:
 ‣ the "preferred key server" signature packet, which allows you to bake a URL your key can be obtained from (in a machine-readable way) directly into your messages https://www.rfc-editor.org/rfc/rfc9580.html#name-preferred-key-server
 ‣ Autocrypt, a scheme for conveying your key along with your preferences for OpenPGP usage in email through mail headers (supported by Thunderbird, Evolution, KMail...)
 ‣ appropriate DNS resource records, such as OPENPGPKEY or CERT
 ‣ RFC 4387: Certificate Store Access via HTTP
 ‣ GnuPG's Web Key Directory
 ‣ GnuPG's include-key-block extension, which bakes an OpenPGP public key packet into your signature like how S/MIME usually works
 ‣ include your key as an "email attachment by reference" as a MIME message/external-body message part, which tells mail clients where your key could be obtained by some URL
 ‣ do like the previous mention, but with a vCard that folks can use to add you to their address books, and with your OpenPGP key information enclosed in there
A good user experience is important for its own sake, but cramming that jargon into an email footer like it's something a human being ought to care about can also be alienating, or even condescending—having ascended an awful heap of rancid garbage in a cargo cult circumstance like this one.

I hope you don't take these criticisms personally. As you may be able to tell, this is a problem space I'm very familiar with.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cinlug.org/pipermail/cinlug/attachments/20260920/1c2717d0/attachment.sig>