[mount-sd] create directory writable for all users. Fixes MER#1010

[deztructor]

Alternative solution (comparing to #17) for the problem of writable directories on posix-compliant filesystems. It is implemented and described in the commit 3ae6881

[thp]

This puts in the assertion that the system user is nemo, and that there's only one user.

[deztructor]

This is just a log record to know what happened (hard to check availability for each/unknown user), I can remove it.

[deztructor]

This solution is proposed as the simple feature until we get something better: we discussed the state of things with @foolab and will try to propose more universal and flexible solution for all this data storage (cards, internal flash etc.) stuff. But the former will be implemented later.

[bwachter]

This proposal will still cause unexpected behaviour for most users by not indexing content on the card due to permission issues. There's no need to rush out a half baked solution breaking in most usecases when advanced users capable of figuring out what's breaking and fixing can just properly prepare their card from the very beginning. For all other users this would just generate support volume.

[deztructor]

@bwachter There should be some solution to allow to store backups on the sd card. Or course, we can say that users of better filesystems should do more steps to get it working but on the other hand this is unfair. This patch does not solve card indexing issue and it was not intended to solve it. It solves specifically one issue and it does not introduce new ones, as also it does not prevent from doing things in a better way :)

[thp]

It adds semantics to directories on the SD card and we'll then kind of have to support that in some way. What about going back to @lbt's patch, but make it so that a system-level dialog pops up and asks if we should make the SD card world-writable (in user-friendly words, like "Change permission, so the device can write indepentent of file owner" or something)? (so not chown, but chmod 777) That's still bad, but it would avoid issues with UID clashes (500 vs 1000 vs $NEMO_UID) and still provide a clean way without littering the user's SD card.

[thp]

Or alternatively:

1.) If SD card is vfat, we're done
2.) If SD card has POSIX-style permissions, check if we can write, if we can, we're done
3.) If SD card has POSIX-style permissions, and we can't write, notify the user of this and offer to reformat as vfat, plus have as a small remark "Alternatively, insert the SD card into your computer and make the root directory of the SD card world-writable." (again, edit for user-understandability)

[lbt]

I was writing a patch which did a chown but cached and restored on umount (lets just hope that we do umount on poweroff or that the UI has an 'eject' :) )

# Ensure that the root of the SD card is owned by our user for the
# duration of the install
fix_root_uid(){
    $CUR=$(stat -c"%u:%g" $MNT/${UUID})
    cat <<EOF > $MNT/${UUID}/.uid_gid_cache
# The uid/gid of the root dir of this card was modified to allow
# access on a mobile device. It will/should have been restored on a
# clean umount but either it's still plugged in or that failed for
# some reason.
# The original uid/gid ownership can be restored using:
#  chown $CUR <path to sd card>
#
# For use by the mobule device:
$CUR
EOF
chown $DEF_UID:$DEF_GID $MNT/${UUID}
}
restore_root_uid(){
    [[ -f $MNT/${UUID}/.uid_gid_cache ]] || return 0
    ORIG_UG=$(egrep -v "^#" $MNT/${UUID}/.uid_gid_cache)
    # Just make sure someone didn't pass us a card with something dodgy
    [[ $ORIG_UG =~ ^[0-9]+:[0-9]+$ ]] || return 0
    chown $ORIG_UG $MNT/${UUID}
}

[bwachter]

@deztructor linux filesystems are currently not supported. It's better to clearly state they're not supported than doing some half assed thing breaking most usecases. To properly support there is the overlay solution as android uses.

@lbt this will break if the user just removes the card, and has other interesting ways of breaking. At least try to be serious, please.

[foolab]

Linux filesystems ARE supported. Me and @iamer spent time making sure we can mount them.

The proposed solution ensures that we have a writable directory for e.g. backups. We already have directories with semantics (Documents, Videos, Music, ...) which we use and I don't see why this case is bad.

A bigger plan is to allow aps to make use of that directory to store their data there but it needs to be documented and discussed.

[deztructor]

@bwachter please take a time to understand my patch and describe use cases it breaks

[deztructor]

@thp @lbt this patch introduces single directory with specific name (not so hard to support this semantic in future) but does not affect overall file system setup on the card, so it is not so intrusive and has less points of failure

[lbt]

@bwachter I am being serious - try to have some respect.
Of course it will break if the user pulls the card out. At least it leaves a nice explanation on the off-chance that happens. It can also use the notification system to inform the user what's happening. As you well know, most linuxy filesystems need a clean umount but this means a UI should support an "eject" style interface too. Each of these things will increase the robustness of the system.
Heck for the Jolla case we could even consider a umount (or notify the user the fs is in use and not to remove the SD) when the ToH is taken off.

@deztructor @foolab I wonder if we could merge the ideas - I like the idea of something like /home/nemo/External mapping to a dedicated directory in the root of the SD card - but I also like the idea of being able to access (and even see via tracker) media files etc on the card which are readable and not in that directory.

[faenil]

isn't it possible to just configure tracker so that it scans the dedicate nemo-specific folder as well as the directories in the root of the SD?