info 1.0.4.20: ext. sdcard - directory change
Content of ext. sdcard can be found now in: /media/sdcard/xxxx-xxxx
Ok... ;)
We have moved to a new Sailfish OS Forum. Please start new discussions there.
Content of ext. sdcard can be found now in: /media/sdcard/xxxx-xxxx
Ok... ;)
Let me say first that normal users (those who do not use a terminal app or tinker with their filesystem) are not affected by this change at all. If you are one of them then feel free to skip the rest of the reply ;-)
Why has that been changed? Simply tracker needs to compute a UUID for each SD card. Don't have a way to provide such UUID to tracker except by: 1) Bringing on board gvfs and udisks2 -> massive change, more memory consumption, extra layers needed for nothing. 2) ensure that the mount point is named uniquely per sd card to ensre that tracker can fallback to its manual uuid computation (which happens from the name of the mount point) -> makes it harder to keep the path to the sd card the same.
The decision has been taken to use option #2. - less intrusive change. - less memory footprint - less maintenance work. - Easily allows mounting cards with mutiple partitions.
For 99.9% of the users, they expect the card content to simply show up and that is what happens. Some users want to use the sd card directly via a file manager which is also fine. This functionality was never announced as a supported API. The fact that it worked previously is an accident. Are we left out in the cold? No, we are now checking if QStorageInfo can be used to provide the API needed for apps to access the card.
This does affect normal users -- anyone who is using an app which stores files and who wants to store those files on their sdcard (in practice, apps do not handle the sdcard specially -- you have to work through the filesystem to get to it). Admittedly the previous mount point was bad, but the new one is even worse at it contains a very long string that means nothing to most people, and changes as they put different cards in.
I still think that that was a wrong decision. The world would be better if tracker had been taught how to properly handle removable disks -- it should be finding the UUID and storing that in its database, not exposing users to the UUID. However, even if fixing tracker was not feasible, the per UUID mount points should not be the ones users and apps are using -- there should be another mount point, with a fixed name, in /home/nemo (say /home/nemo/sdcard). Of course, tracker has to be configured to not index that directory, in order to complete the workround.
gcobb ( 2014-03-18 19:30:59 +0200 )editEdit 14/03/25 : Workaround no more needed with the today's release of CargoDock
As a workaround, and without using command line (developer mode is needed) :
You now have a bookmark to the memory card in Places (go to the right pane to see it)
I hope this helps.
IF YOU ARE A HACKER...
I have created a patch for /usr/sbin/mount-sd.sh which helps alleviate this problem by creating and removing a softlink in the /home/nemo directory as the sdcard is mounted and unmounted. The softlink is called "/home/nemo/sdcard". If it is present it points to the sdcard, if it is absent the card is not mounted.
This hack only works with one partition on the sdcard (which is normally the case). If you have more than one partition, the softlink could end up pointing to any of the mountpoints.
This works for me but I have only tested it on my phone and with my SD card. It might not work for you. It could even cause a problem booting your phone (although rebooting with no SD card inserted should avoid running the script at all). And, of course, this is completely unsupported by Jolla.
DO NOT TRY THIS UNLESS YOU ARE CONFIDENT WITH EDITING SYSTEM FILES ON YOUR JOLLA
BACKUP THE ORIGINAL VERSION OF /usr/sbin/mount-sd.sh BEFORE YOU START EDITING IT
Here is the patch...
--- mount-sd.sh.sav 2014-03-18 21:15:36.205880491 +0000
+++ mount-sd.sh 2014-03-18 21:30:53.010035338 +0000
@@ -53,13 +53,14 @@
mount ${DEVNAME} $MNT/${UUID} -o $MOUNT_OPTS || /bin/rmdir $MNT/${UUID}
;;
esac
- test -d $MNT/${UUID} && touch $MNT/${UUID}
+ test -d $MNT/${UUID} && touch $MNT/${UUID} && ln -sf $MNT/${UUID} /home/$DEVICEUSER/sdcard && chown $DEF_UID:$DEF_GID /home/$DEVICEUSER/sdcard
systemd-cat -t mount-sd /bin/echo "Finished ${ACTION}ing ${DEVNAME} of type ${TYPE} at $MNT/${UUID}"
else
DIR=$(mount | grep -w ${DEVNAME} | cut -d \ -f 3)
if [ -n "${DIR}" ] ; then
umount $DIR || umount -l $DIR
+ test -L /home/$DEVICEUSER/sdcard && rm /home/$DEVICEUSER/sdcard
systemd-cat -t mount-sd /bin/echo "Finished ${ACTION}ing ${DEVNAME} at ${DIR}"
fi
fi
Oh and by the way, if you do use my changes, you can also do (as nemo, no need to use root):
ln -s /home/nemo /run/user/100000/media
And then old apps which want to access /run/user/100000/media/sdcard will work again. However, you have to set up the link again after every reboot so you really want to fix the apps.
gcobb ( 2014-03-19 00:06:06 +0200 )editAnd before anyone points out "there is no need to change ownership of the softlink", I did it to avoid user confusion when they look at the directory. Many users may not realise that they could replace the link if they need to, even though it is owned by root. So purely cosmetic!
gcobb ( 2014-03-19 11:32:47 +0200 )editIf you want the same behavior as before the update, a simple way is to create the requested directory and place the link as :
[nemo@localhost ~]$ cd /run/user/100000
[nemo@localhost 100000]$ mkdir media
[nemo@localhost 100000]$ cd media/
[nemo@localhost media]$ ln -s /media/sdcard/{your-uuid} /run/user/100000/media/sdcard
And here a permanently solution :
[Unit] Description=Run applications at startup Requires=lipstick.service After=lipstick.service [Service] Type=oneshot ExecStart=/bin/mkdir /run/user/100000/media ExecStart=/bin/ln -s /media/sdcard/xxxx-xxxx /run/user/100000/media/sdcard [Install] WantedBy=post-user-session.target
I hope it helps, for me it works
Thanks to Nux for Answer Jan. 7 Nux
I updated my answer, so you have a non temporary way
greetings
michaelmischke ( 2014-03-21 00:44:46 +0200 )editThis thread is public, all members of Together.Jolla.Com can read this page.
Asked: 2014-03-18 01:20:33 +0200
Seen: 2,048 times
Last updated: Mar 25 '14
Bug: SD card formatted to ext4/btrfs is not mounted automatically [released]
My Jolla does not recognise any micro sd card. What I can do? [answered]
[Fixed in 1.0.3.8] Crash when linking contacts? [not relevant]
Time slider usage in video player of Gallery app causes the app to hang [duplicate]
QAudioOutput isn't integrated with system volume and libresource like QMediaPlayer
Bug: E-Mail synchronization does not work as configured [released]
Word prediction should be always turned off when entering passwords in Android apps [released]
Don't enforce focus to textfield [answered]
[Implemented in 1.0.3.8] Email: Honour Reply-To header [answered]
Do you know of any way to address it from a script? before it used to be $XDG_RUNTIME_DIR/media/sdcard/
I checked env and set but couldn't find a variable addressing it...
icebox ( 2014-03-18 14:47:07 +0200 )editThis is a really bad change. The change has been made deliberately to handle cards with multiple partitions and the stupid long name is to workround a tracker bug where tracker does not record the device information but just the file name. So, every user is made to see a stupid name just because of a tracker bug?
gcobb ( 2014-03-18 18:10:17 +0200 )editIt is essential that Jolla add a fixed link somewhere in the filesystem to use to reference the 99.999% case where the user has inserted an sdcard with one partition and has never heard of a UUID! When a card is inserted, one partition (any one, as almost all cards in the world only have one partition) should be mounted somewhere easily accessible to the user (probably somewhere in /home/nemo so apps with simple file handling allow users to access the sdcard).
gcobb ( 2014-03-18 18:13:39 +0200 )editThe change is not the issue that needs addressing. The lack of documentation is. This change should have been clearly documented in the change log, and in the relevant FAQ/Wikis etc. Then all (users, developers etc) have a chance to understand the change instead of reporting designed behavior as bugs. It would be good maybe if the technical reasons for this could be shared. As a semi technical user I am not sure I understand the benefit of this approach, and am keen to understand.
PJW_2273 ( 2014-03-18 18:29:41 +0200 )editThis might be better (untested)
MSameer ( 2014-03-18 20:17:40 +0200 )editmount | grep mmcblk1 | cut -d \ -f 3