[Improvement] Enhanced mounting scripts for SD-cards

Thanks for your prompt reply, which deserves a few comments IMO:

• 4) Your commit 6 months ago is not what I was "looking for" / aiming at, as it ultimately issues a single ln -s /run/media/nemo /media/sdcard after deleting all directories in /media/sdcard.
  On first sight, this is what SFOS 2.2.x already deploys, right?
  Some older SFOS apps are not happy with that, so that did not solve the "compatibility issue" for them; issuing ln -s /run/media/nemo/<UUID> /media/sdcard/<UUID> for each partition / device found restores their SD-card related functions (e.g. FileCase).
  Edit: Sorry, now having more time available and looking more thoroughly, I see that SFOS 2.2.x issued a ln -s /run/media/nemo /media/sdcard/nemo, not ln -s /run/media/nemo /media/sdcard as your aforementioned commit ultimately does.
  Yes (without having tried that, yet), this change seems to resolve the compatibility issue more elegantly than my suggestion. Although I refrain from adapting mount-sdcard to it, as I would have to delete filesystem elements deployed by Jolla (i.e. the /media/sdcard/nemo symlink), while I want to interfere as little as possible with your past and current work.
  Side note: When reviewing your script, it seems to expect solely empty directories (as potential mount points) in OLD_MOUNT_PATH (i.e. /media/sdcard), but appears to fail if symlinks (e.g. Jolla's nemo link or the ones deployed by mount-sdcard), files or non-empty directories (accidentally or deliberately created by a user) exist there. This may be alleviated by also deleting symlinks in /media/sdcard (e.g. by an additional [ -L ${path} ] && rm -f ${path} in the for loop), before deleting empty directories there, as both operations cannot delete any actual data (but an rmdir may delete an empty directory symlinked to). If that does not suffice (i.e. non-empty directories or files do exist in /media/sdcard), IMO failing is the right option.
  Edit2: Oh, this is what SFOS 2.2.x already deploys, and it creates a symlink /media/sdcard/nemo -> /run/media/nemo, if /media/sdcard contains anything else but empty directories (ln's behavior is somewhat surprising, if the source for a symlink is an extant directory). This PR fixes this.

• 3) Thank you for creating a PR.

• 1) and 2) are the really crucial points IMO, i.e. the ones the original posting primarily addresses, hence your non-answer is a bit disappointing for me.
  Side note: Your current mount-sd.service is elegant and easy to adapt, plus it was just altered to utilise udisks in SFOS 2.2.0, hence I expected it to stay (and based my improvements upon it).
  Anyway, whatever substitutes it, shall properly address issues 1. and 2., IMHO.

Best regards and a pleasant weekend for you, too.

BTW, others also observed an incorrect symlink created by this script:
See e.g. "SDcard symlink is incorrect" or @eatdirt's comment in "Path to SDCard, 2.2.0.29".

@rainemak, #3 is also applicable to the udisks-rule 90-mount-usbstick.rules, which was introduced in SailfishOS 3.0.0.

Well, with a proper Android file-manager (e.g. "OI File Manager" installable per F-Droid client app), one can "see" and read everything on SD-card by navigating to /run/media/nemo (since SailfishOS 2.2.0, before: /media/sdcard).

But most Android apps only allow accessing Android's "external SD-card", which is mapped to "android_storage" by AlienDalvik (in nemo's homedir on internal eMMC).
If you want such Android apps to read and write to SD-card, you have to reconfigure android_storage to reside on SD-card.
As some data in android_storage may be privacy relevant (browser history, pictures, downloads, etc.), it might make sense to put it on an encrypted partition on SD-card. But for putting android_storage on unencrypted SD-card, above enhancements are indeed useful.

Thanks for your time. I see it's a little difficult procedure, and i have some doubts... What will happens if i modify it and then i update to SFOS 30, which is about to arrive? Should i roll it back first?

@campeon, if "it" in

What will happens if i modify it and then i update to SFOS 30, which is about to arrive?

adresses the single line change in /opt/alien/system/script/platform_envsetup.sh:
I don't know what exactly SailfishOS 3.0.0 will bring, but supposedly (as usual on SFOS updates) nothing "happens". At worst, android_storage is not mounted automatically anymore, but can be mounted manually at the command line. So, if you want to revert something, you can do it anytime after an SFOS upgrade.
~~Furthermore the RPMs of mount-sdcard and crypto-sdcard will be automatically uninstalled when upgrading to SFOS 3.0.0.~~ Edit: Recent versions don't, because they run well with SFOS3. But if you still feel uncomfortable with employing these changes, you might better leave it.