info 1.0.4.20: ext. sdcard - directory change

answered 2014-03-19 22:44:17 +0300

MSameer
2137 ●21 ●44 ●32

have reported an issue against file manager and it's now fixed in git. I have also posted on TMO CargoDock thread to inform the developer that the sdcard access is now broken. Hope it will also be fixed soon and new releases will come out.

answered 2014-03-19 17:14:18 +0300

Sa
181 ●3 ●4 ●7

updated 2014-03-25 21:41:23 +0300

Edit 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) :

• Open CargoDock
• in the first pane go to System / Media / sdcard (you should see the UUID of you memory card xxxx-xxxx)
• Select the xxxx-xxxx folder with a long press
• and with a pull up, select Bookmarks

You now have a bookmark to the memory card in Places (go to the right pane to see it)

I hope this helps.

answered 2014-03-19 12:38:01 +0300

michaelmischke
66 ●3 ●6 ●11

updated 2014-03-21 00:41:47 +0300

If 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 :

1. Log in as user nemo (e.g. with WinSCP or PuTTy).
2. In "/home/nemo/.config/" create "systemd".
3. In "/home/nemo/.config/systemd/" create "user".
4. Create "autostart-apps.service" (see below) in "user" dir.
5. Install autostart service: systemctl --user enable /home/nemo/.config/systemd/user/autostart-apps.service. "autostart-apps.service" file:

[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

answered 2014-03-18 23:53:18 +0300

gcobb
1660 ●19 ●31 ●35

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

answered 2014-03-18 18:54:59 +0300

MSameer
2137 ●21 ●44 ●32

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.

answered 2014-03-18 01:52:36 +0300

HighCast
1936 ●17 ●21 ●22

Thank you. As I'm not a Linux user - except by SailfishOS way - and the File Manager is not updated yet - there was no clear way to access my SDcard. Thanks for the update.