Personally I can see people temporarily swapping SD cards so they can
try out other peoples apps on their phone, so I can see the need to
handle it properly.
Al.
--
* Looking for Android Apps? - Try http://andappstore.com/ *
======
Funky Android Limited is registered in England & Wales with the
company number 6741909.
The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.
If I missed any features, or miscategorized any, etc please update the
doc. Please don't destroy it. (Does google docs have wave-style undo?)
Just my 2 cents: I also think it is a good idea to use an overlay
filesystem instead of a loop mounted image file. I think it is easier
to handle, and may provide a user with a more seamless experience. For
example: if the user installs an app on the sdcard, then decides to
delete it. In order to reuse the space that now should be available
(at least the user will think so!), the image file must be shrinked.
When an overlayed filesystem is used, such extra steps are not
necessary, everything works as expected, from the user's point of
view.
The root directory for this filesystem could be marked system + hidden
to signal to users that the they should not mess with the contents
manually, when the sdcard is mounted on a PC.
I am not sure about the performance implications of using Fuse,
probably it would be good enough.
I recall, that in the early days of Linux there was a similar
filesystem that overlayed on msdos filesystems. I don't know if that
FS is still maintained, or if it would be a good idea to use it.
There is one issue with overlays: applications (malicious or simply
buggy) could allow the user to peek under the hood. One solution to
this is to use 2 overlay file systems:
Under /sdapps (or whatever) the system mounts the sdcard applications
and any other directories needed (data, cache ... etc.)
Under /sdcard a very simple overlay is mounted, which simply hides the
storage directory of the sdapps filesystem. This could even be
implemented in kernel space to minimalize the overhead.
What do you think?
Best Regards,
Gergely
I'll check the rest of the email later and give a better response :)
On Thu, Oct 29, 2009 at 10:46 AM, lbcoder <lbc...@gmail.com> wrote:
> There are precisely TWO places where you can create a filesystem;
> either in its own partition (discussed and rejected -- reason being MS
> hostility routines), or as a loopback filesystem within the existing
> fat32 filesystem.
The third place addresses your next point as well - an encrypted (or
signed) overlay on top of the existing filesystem. (EG encfs). And
note that encryption is not required here - the user SHOULD have
access to their data, just as they would on the onboard flash. What
MUST be in place is protecting one app's data from another.
> There is also a possible future need for encryption at a filesystem
> level. This is simply irreconcilable with USMDOS type filesystem
> overlays. We would definitely be restricted to file-level encryption,
> and with a lot of files, this makes things messy.
> The SECOND use is for HOME DIRECTORY and DALVIK CACHE entries. This
> filesystem could be set up such that ALL package home directories and
> dalvik cache entries appear in the expected location -- /data/data,
> and /data/dalvik-cache. The filesystem can INTELLIGENTLY union entries
> in these locations by UID/GID/filename/etc., i.e., on mount, it adds
> the sdcard files in with the internal files, when new files are
> created, it intelligently chooses where those files are to reside
> based on the UID/GID/filename assigned to that file -- if the ID or
> path name matches an external app, the file is created on the external
> filesystem. If the ID or path name matches an internal app, the file
> is created on the internal filesystem. The really nice thing about
> THIS is that it entirely solves the problem of apps accessing their
> home directory by *absolute path*, which means that it won't break ANY
> app. Also note that with this scheme, the home directories and dalvik-
> cache of unauthorized apps can be LEFT OUT from the /data/data and /
> data/dalvik-cache.
Bind mounting would allow remapping /data/data/ as needed without
having to change anything extra or do any coding. (FYI)
(Dianne, cc'd you - can you confirm whether or not
"/data/data/appname" is required to work? Or is it enough to just
support openFileInput and related?)
On Thu, Oct 29, 2009 at 12:49 PM, lbcoder <lbc...@gmail.com> wrote:
>
> How does that help for applications that already access their (or
> others) home directories by absolute path?
> http://developer.android.com/reference/java/io/File.html#getAbsoluteFile%28%29
>
> See, we've got this crazy little thing in that one can generally guess
> about what their absolute home directory path will be given that it is
> in the form of "/data/data/packagename". It may not be a smart way of
> doing it, but it can be (and often is) done. Not taking this into
> account *will break* all applications that use this approach.
>
And so will a new device that perfectly legally creates /system,
/appdata and /packages. Or /system, /appdata, /appdb.
(There are lots of crazy things that break between platform revisions.
And ISTR you generally assume anyone who has broken code between
releases did something wrong. Like, say, making assumptions about
where the data files will live.)
I think your points are valid, but I am concerned with using a regular
loop mount and this whole shrinking / extending business.
Also, using a general purpose FS like ext3 in a loop mount is probably
not very efficient when used on an already slow Sdcard, on a not very
powerful hardware.
So I was thinking of using a special filesystem that was designed for
exactly this use-case:
- stores the contents in a few larger files (to get around the 4GB
maximum file size limit for example)
- it shrinks / extends its data files as necessary
- it provides full posix semantics
- it can encrypt parts of itself for security
- it includes integrity checks.
So I went to the FUSE homepage, and found MetFS.
(http://www.enderunix.org/metfs/index.php?sect=main&lang=en)
It promises something similar, but its implementation is not even on
the proof of concept level. Also, it uses an external work directory,
so it is a no-go.
I really hope, that someone-somewhere already wrote a filesystem for
fuse that could be used as a starting point.
Using a good Fuse (user space) implementation would make the system
probably more robust when the sdcard is yanked out of the phone, but
maybe it is just an preconception from previous bad experiences.
For a very first try, one of the Fuse archive file systems could be
used: http://sourceforge.net/apps/mediawiki/fuse/index.php?title=ArchiveFileSystems
Of course I am almost sure that none of these provide complete POSIX
semantics...
Best Regards,
Gergely
On Thu, Oct 29, 2009 at 3:46 PM, lbcoder <lbc...@gmail.com> wrote:
>
> Gergely:
>
> I have considered that, but have come to the conclusion that it is
> quite impossible, or in the least, impractical.
>
[....]
I really don't think a2sd is a good solution at all (I've been following the discussion at android groups), rather, I believe the lack of an a2sd solution will eventually lead to device manufacturers to increase the amount of internal storage available on the device for applications (this is what this project is all about, isn't it, not enough storage for apps?) like Samsung did with it's Galaxy.
We shouldn't assume that a device is going to be used a particular way because then we'll run into problems. We shouldn't assume that an user will want to have their device used that particular way, be it partitioned or with a custom, secure filesystem stored in the SD. How do we explain that they'll lose some of their sdcard to app storage? If we make it automatic, how do we allow the user to disable it if they do not want it? How do we make it if an user wants to have one SD card with apps on it and another one without them?
Again I believe we should let the demand for more storage drive the evolution for the next android devices instead of just making it work and have manufacturers ignore the real need for increased internal storage.