We have moved to a new Sailfish OS Forum. Please start new discussions there.
18

info 1.0.4.20: ext. sdcard - directory change

asked 2014-03-18 01:20:33 +0200

Moth gravatar image

updated 2014-03-18 18:21:28 +0200

gcobb gravatar image

Content of ext. sdcard can be found now in: /media/sdcard/xxxx-xxxx

Ok... ;)

edit retag flag offensive close delete

Comments

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 )edit

This 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 )edit

It 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 )edit
1

The 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 )edit

This might be better (untested) mount | grep mmcblk1 | cut -d \ -f 3

MSameer ( 2014-03-18 20:17:40 +0200 )edit

6 Answers

Sort by » oldest newest most voted
11

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

MSameer gravatar image

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.

edit flag offensive delete publish link more

Comments

1

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 )edit

While you are looking into future solutions, is there a DBUS signal in 1.0.4.20 I can watch from my app to know that a card has been inserted (or removed) and I need to go and search some directories to find the user's new sdcard location?

gcobb ( 2014-03-18 19:43:27 +0200 )edit
7

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

Sa gravatar image

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

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.

edit flag offensive delete publish link more

Comments

great solution !! Thanks a lot !!

Manankanchu ( 2014-03-19 21:55:03 +0200 )edit

My issue is that I can not see now my sd card y cargo dock, nor in fileman: I am a normal user

estatarde ( 2014-03-20 10:17:06 +0200 )edit

The developer mode is needed to see "System" folder. I've added this to my answer.

Sa ( 2014-03-20 22:08:05 +0200 )edit

great! thanks too!

estatarde ( 2014-03-22 17:06:53 +0200 )edit

The UUID and thus the bookmark will remain valid until you reformat the card.

MSameer ( 2014-03-28 03:12:21 +0200 )edit
2

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

gcobb gravatar image

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
edit flag offensive delete publish link more

Comments

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 )edit

And 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 )edit
2

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

MSameer gravatar image

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.

edit flag offensive delete publish link more

Comments

File manager has been released, it seems to be ok now.

(Cargo Dock not yet released)

Sa ( 2014-03-22 13:58:26 +0200 )edit

cargodock release is out but seems not in harbour yet.

MSameer ( 2014-03-25 17:46:50 +0200 )edit

I've just checked and Cargo Dock release is now in harbour !

Sa ( 2014-03-25 21:42:49 +0200 )edit
1

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

michaelmischke gravatar image

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

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

edit flag offensive delete publish link more

Comments

That is a good suggestion but, unfortunately, it has to be repeated after every reboot (/run is a tmpfs).

gcobb ( 2014-03-19 22:11:31 +0200 )edit

I updated my answer, so you have a non temporary way

greetings

michaelmischke ( 2014-03-21 00:44:46 +0200 )edit
0

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

HighCast gravatar image

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.

edit flag offensive delete publish link more

Comments

Both File Browser and Cargo Dock have shortcut to access SDcard. Dont't they work anymore after 1.0.4.20?

spacenewt ( 2014-03-18 02:01:27 +0200 )edit

At least for Cargo Dock: No.

Moth ( 2014-03-18 02:03:51 +0200 )edit

Nor for File Browser

strongm ( 2014-03-18 04:03:09 +0200 )edit
2

IMO, previous location seemed insane and new one makes more sence.

mcfrisk ( 2014-03-18 11:27:20 +0200 )edit
1

New place it make more sense than previous one. :)

tvicol ( 2014-03-18 12:00:19 +0200 )edit
Login/Signup to Answer

Question tools

Follow
9 followers

Stats

Asked: 2014-03-18 01:20:33 +0200

Seen: 2,037 times

Last updated: Mar 25 '14