[guardian-dev] IOCipher multiple containers

[zoki]

I tried that (discussion above) but I have a problem:
https://www.pastiebin.com/58b942a5c304b

- I start a service (in different process than app) where I create or mount
an iocipher container. I'm playing files from it and when I'm done I detach
all threads and unmount container (snippet below) and stop service
(stopSelf; onDestroy on service is called).
- When I start again I see that service is created again (onCreate in
service is called) and I repeat a process same as before (iocipher
container is mounted, reading from container for playing, when done detach
all threads and unmount and stopService....)
- After repeating that 4 or 5 times I get a crash (log is above)

I have more thread because I two schedulers.

I detach threads like this (there are always 3 or 4 active threads):

int i = 8;
VirtualFileSystem vfs = VirtualFileSystem.get();
while (i > 0 && vfs.isMounted()) {
    try {
        vfs.unmount();
    } catch (IllegalStateException e) {
        vfs.detachThread();
    }
    i--;
}

Unmount on the end is always successful, but is this the correct way of
unmounting container? Can be problem here?

For playback I'm using custom content provider (
https://github.com/n8fr8/CameraCipher/blob/master/src/info/guardianproject/iocipher/camera/io/IOCipherContentProvider.java).
Can be problem somewhere here that pipe is not closed? How could I check
this?

I would be very glad if someone could point me to any direction where to
check for errors why is this crashing. Thanks!

On Fri, Feb 10, 2017 at 12:21 PM zoki <zoran.smilevski at gmail.com> wrote:

> Thanks.
> Service and provider in another process looks like a way to go. Will try
> that.
>
> On Fri, 10 Feb 2017, 11:16 Hans-Christoph Steiner, <
> hans at guardianproject.info> wrote:
>
>
> hey Zoki,
>
> It is theoretically possible to use multiple containers, but it is not
> well tested and it is not the use case we have in mind for it.  IOCipher
> is designed around the idea of having a single file system that is
> dedicated to the app.  It was not really designed to be general purpose
> "containers".  That said, there is no technical limitation that would
> prevent IOCipher from handling multiple containers.  Its mostly a
> question of how to design a good API for that.  IOCipher uses
> java.io.File as the API, there is no way to specify which container to
> use in that API.  Having a global "switch container" method seems like a
> recipe for many super confusing bugs.
>
> I think starting a Service in its own process for each container would
> be the best way to do that with IOCipher as it is now.
>
> .hc
>
> zoki:
> > Hello, I have few questions regarding using multiple iocipher containers.
> > Is it possible to use multiple containers at the same time? Or at least
> > easy switching between them?
> > I don't know how to use them because VirtualFileSystem is singleton. I
> > guess that has some purpose, can someone please explain why?
> >
> > Now with new ExoPlayer which has support for playing from content
> provider
> > is very easy to play videos from secure container. I'm thinking to use
> > another container for caching video files, because it's easier to delete
> > container files and free storage rather than doing container shrinking.
> > Would I need to start new process for that?
> >
> > Thanks for any help :)
> >
> >
> >
> > _______________________________________________
> > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> > To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> >
>
> --
> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170303/06f44ab3/attachment.html>