[solved (suboptimal)] thunar udiskie fickleness - android, cgroups, lost weekend

Rambling hurried post here to be edited down later, but basically breadcrumbs from a basket of unhappiness attempting a USB download of a picture from my phone. Three of us guys took a picture at the football game on celly -- can we even look at the photo on a desktop?

setup

Normal. I have my regular user in the uucp group and libmtp installed per typical. I have EHCI and UHCI USB controllers that easily recognize and mount any USB drive. The phone is cleanly ID'd in lsusb.

solution (still suboptimal)

The only app that could interact with the phone was simple-mtpfs from the AUR (yaourt). The CLI is required to mount and unmount the phone, but GUI is no problem except for mounting/unmounting. Make a directory in ~ called mnt or something else easy to remember and verify that the device has been detected:

$ simple-mtpfs --list-devices #verify detected
$ simple-mtpfs ~/mnt #mount phone
$ fusermount -u ~/mnt #unmount phone

At the same time, one should blacklist auto-mounting from inside ~/.xinitrc. This stops problems with gvfs attempts to automount the phone, or anything else. Auto-mounting usually fails in a way which apparently conflicts with udiskie2.

$ nano .xinitrc
# stop gvfs auto-mounts
export GVFS_DISABLE_FUSE=1

problem

On every system I have but the newest (aka, "DRM"est) one, I connect via USB and thunar detects and displays it. On the new system, even with MTP and all related software installed, I get the following symptom upon USB connection: phone detected, but in installer mode, on the phone the taskbar shows "USB slow charge only", and in the phone main screen, a popup with "Media Transfer Protocol" and a spinning prompt asking me whether I'm on a Mac. This means three different descriptions for the same connection. Unbelievable. Once I click Mac or whatever, I lose the phone on my system, lose the phone screen, and see USB slow charge on the phone status bar. It's outrageously wrong that protocols are this kludged nowadays in the copyright universe (or whatever the ultimate underlying problem is, but typically copyrights/DRM) with proprietary, instead of standardized, file and mounting types. A simple file manager connection is matter of a weekend.

thunar: volman issues

Volman is just not seeing the phone as what it is: if I start thunar from a terminal and connect the phone to a USB, lsusb detects it right down to the model number, but thunar does not, spewing, eg:

thunar-volman: Unsupported USB device type.
thunar-volman: Unsupported USB device type.
thunar-volman: Unknown block device type.
thunar-volman: Could not detect the volume corresponding to the device.

Good discussion about volman with USB is here, including many fellow gvfs and gnome-disk-utility haters (though we can install no-gconf, which helps somewhat). Interestingly, this led to one person, I think on the second page noting they use rox, udiskie, and openbox (esp the openbox pipe menus), but openbox is still too heavy for me, and I don't like rox that much. However, the idea of pipes intrigued me -- if I could get pipes in icewm, I could still use thunar for everything else so: thunar, udiskie, icewm pipes. Found this icepipes discussion, which laid most of it out.

mtab: an old friend reveals another kludge

So was the phone being mounted at all? This led to yet another new issue: cgroups. I catted /etc/mtab, an old friend that simplifies viewing what's mounted (eg. where is my f*cking phone?), if mounted. This time, in addition to the 4 or 5 entries I expected, I was greeted with an additional 8 unknown mounted file systems from who knows where in my system and so eating who knows how many processor slices or memory blocks:

tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0

... as well as these 6 beauties...

debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0

... for a total of 14 new-to-me, unknown, mounted file systems, but I can't mount my f*cking phone without creating an fstab for that model? I guess the end-user is just becoming a nuisance. Anyway, a panicked df followed, and this thankfully only revealed 3 (still too many) of these new tmpfs entries. Why wasn't this on the evening news?