Hello Jamie Strandboge, Thanks for your reply
(...) > This is a complicated topic and currently app-access to the SD card is not > fully > implemented. This has been discussed in the past and the main points are: > > * we don't want to allow a shared storage area like <SD CARD>/freeforall > because that breaks application isolation I totally agree here > * we could try to do something like: > owner <SD CARD>/<USER>/<PKGNAME>/** rwk > similar to the app-specific directories in /home, but that only works well > with Linux filesystems (eg, ext4) because some filesystems may not support > case-sensitivity, separate UIDs (for multiuser systems) or long filenames This folder could be unreadable by the user, when connecting to the computer. Especially when it is a hidden folder like the app storage in home. > * Most things in Ubuntu Touch aren't aware of the SD CARD and the user > experiences have not been defined > > Because of this, only a couple of apps have special exceptions that grant them > access to the filesystem. > >> Picture read could be possible, however it needs the maps >> to be placed in <SD_CARD>/Pictures/osmscout. That is an ugly solution, >> but it works. > It does work in the sense that your app now has access to the folder, but it > almost certainly doesn't work in the gallery, mediascanner, etc that have to > deal with GBs of data that are in a subfolder that it scans for updates. Those > apps would have to be updated to ignore the osmscout subfolder, which is even > uglier. I totally agree Pictures is not the way to go, this was the first folder that I could get myself access to using simple rules. > >> Another solution is to set the app as unconfined, and use the location >> <SD_CARD>/Maps/osmscout. However this is not the solution to allow for >> any app, I think this app really adds value to the Ubuntu phone. >> Would it be possible to create an app-specific rule that allows (Read, >> and maybe later Write) access to <SD_CARD>/Maps/? Or otherwise to allow >> this app to be published as unconfined? >> > There is no reason to run it unconfined when an app-specific directory could > be > used instead. As far as exceptions go, this is the cleanest solution because > only your app would have access to this directory. Because of the > case-insensitivity, you would need to do something like this: > read_path: [ > "/media/*/*/[Mm][Aa][Pp][Ss]/" > ] This is what I also did in the latest version that I uploaded (well, a slightly different syntax but I will copy the line above) When I first uploaded a version i was unaware of the possibilities of such custom rules. > > However, if you add that, what happens if the user has an Ubuntu Touch device > that doesn't have an SD Card (eg, the reference Nexus 4)? AIUI, most new > devices > have a lot more storage and many are foregoing SD card support altogether. For that reason I would also like to request access to another folder in the home directory. e.g. $HOME/Documents/Maps. This way the app can automatically check where maps are located, and let the user choose. > Now, this doesn't deal with all the other problems with non-Linux filesystems > on > the SD CARD. > > I've included Thomas Voß in this email because he may have more information on > the current status. Thomas (please forward if someone else knows), > * what is the current status of SD CARD access by apps, especially wrt > multiuser (UID mappings), case-insensitivity and short filenames? Is there > a > roadmap? For my app this wouldn't be a big problem, as long as I define the rule as [Mm][Aa][Pp][Ss] > * is there a better way to handle map data? It seems like Frans is having to > deal with a lot of difficulties here with pregenerating map data and > getting > it onto the SD Card. Are there plans for a maps service or something? Well there isn't much of a problem, as long as the reviewer allows me to create a rule dealing with read_path. OSMScout is using a custom binary map format, which is converted from .osm xml using a simple application based on libosmscout. I don't think these maps would be useful in any way for applications that are not based on libosmscout. > * should we create a restricted 'maps' policy group that allows '~/Maps' and > '/media/.../Maps' like how the gallery current owns '~/Pictures'? The > question then is, who is the actual owner of Maps (ie, osmscout isn't like > gallery)? I don't think a map policy would be necessary at this point, as the read_path (and eventually write_path when downloading maps will be done through the app) does the job very well. Thanks again for your input. Frans >
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
