It's difficult to contribute to OpenPandora development. First, there is a bit of confusion with development separated all over the place. Second, you guys depend on a underdocumented and outdated project like OpenEmbedded (good thing we're moving away from it). Third, the separation all over the place creates confusion/madness. I thought that the development happened on the github (way easier to interact with) and I've sent a few pull request there, just to be warned to move later. Fourth, when I tried bugs.openpandora.org, the system seems broken (it isn't accepting my bug-report/patch and even still, I had to upload the patch to gist.github.com, because there was no attachment button). And no we have this mailing list, with a broken web interface where I can only request a new account through emails sent to address-that-i-don't-remember-how-i-got.
Enough of my rant, let's do business...
I'm attaching the patch on this email. You can find more details about it in the file contents. You can apply it with git apply (it was generated with git format-patch), although I never really used it. The patch is also hosted on gits: https://gist.github.com/vinipsmaker/8795487
This change only affects automounting behaviour. The "manual" mounting through the Thunar file-manager continues to get the argument wrong. I'll study the hal architecture and see how I can tune the system even further.
Em Seg, 2014-02-03 às 22:05 -0300, Vinícius dos Santos Oliveira escreveu:
This change only affects automounting behaviour. The "manual" mounting through the Thunar file-manager continues to get the argument wrong. I'll study the hal architecture and see how I can tune the system even further.
Well, I did my research.
The first step was lucky. Sometimes when I try to umount the SD card, I see a complaint about an error mentioning org.freedesktop.hal.storage. The result was that I got an relevant information: XFCE uses DBus/hal to mount volumes.
The second step was a shitload of tests and reading a lot of documentation to understand how to use DBus (and it is easy and very pleasant, btw) and hal to mount volumes. The relevant part is: you use the method org.freedesktop.Hal.Device.Volume.Mount (as in the attached script3.sh) method to mount something. The third argument to this method is a list of extra arguments. By default, hal won't mount vfat filesystems with the utf8 arg (but recognize it as a valid argument), which is consistent with mainstream and modern distros (and it's also consistent with what you get if you try to mount via command line). If you don't pass the utf8 arg explicitly, it won't be used.
After I confirmed the behaviour with my scripts and mounting manually using the same methods that XFCE might use, it was time to verify that the error was indeed originated in XFCE. So third step was to use dbus-monitor to monitor any DBus/hal interactions with my volume. The following command should let you monitor it:
dbus-monitor --system path=/org/freedesktop/Hal/devices/volume_uuid_D7FD_0C27 # use script2.sh to discover the path argument
But I couldn't monitor any method calls. I tried to run as root and got nothing. I found this[1], but it didn't work. I don't know (and I don't want to know) how to tune DBus daemon to allow me to do my job. So this means that I cannot prove my "feeling", but I'm confident enough that the problem lies on XFCE and I proceed.
tl;dr: The fourth step brought me to this link[2], which solves the problem (I tested it already). I can provide a patch later, but my first patch (on the first email) solves another problem and it should be merged already.
[1] http://www.piware.de/2013/09/how-to-watch-system-d-bus-method-calls/ [2] https://bbs.archlinux.org/viewtopic.php?pid=760397#p760397