On Tue, May 29, 2012 at 4:00 PM, Latimerius wrote:
> > What you are indeed seeing is just standard Linux filesystem semantics
> where
> > the storage for a deleted file is not reclaimed until nothing is using it
> > any more. In this case, creating the Context on the .apk has opened that
> > .apk
On Wed, May 30, 2012 at 12:20 AM, Dianne Hackborn wrote:
> On Tue, May 29, 2012 at 9:10 AM, Latimerius
> wrote:
>>
>> Yeah, I know, a standard idiom using temporary files actually relies
>> on this, I was just pondering how come someone has (tens of) my asset
>> files open that I myself haven't t
On Tue, May 29, 2012 at 9:10 AM, Latimerius wrote:
> On Tue, May 29, 2012 at 5:54 PM, Kostya Vasilyev
> wrote:
> >
> > ... but also keep in mind that Linux (and other Unixes, AFAIK) allows for
> > currently open files to be deleted, deferring the deallocation of actual
> > backing bits in the fil
On Tue, May 29, 2012 at 6:38 PM, Jason Teagle wrote:
> (To the OP)
>
> I may be missing something here, but why do you use a cached reference to
> package B's context?
A is the actual application, B is a data disk, expansion or whatever
you call it. A needs to be able to access files in B just a
(To the OP)
I may be missing something here, but why do you use a cached reference to
package B's context?
I believe you said that trying to grab the context after B has been
uninstalled fails, as expected - so why not use this as a test to see
whether A should be allowed to go ahead and use
On Tue, May 29, 2012 at 5:54 PM, Kostya Vasilyev wrote:
>
> ... but also keep in mind that Linux (and other Unixes, AFAIK) allows for
> currently open files to be deleted, deferring the deallocation of actual
> backing bits in the file system until all references have been closed.
Yeah, I know, a
2012/5/29 Mark Murphy
> On Tue, May 29, 2012 at 11:19 AM, Latimerius
> wrote:
> > I don't know...I thought of this but I wasn't able to confirm it. A
> > can access files after B's uninstallation that were never read or even
> > opened before B's uninstallation. Unlike the test, in the actual
On Tue, May 29, 2012 at 11:39 AM, Latimerius wrote:
> Well, from the replies in this thread it appears that the behaviour is
> not documented and it wouldn't be such a great idea to rely on it...
Agreed.
> shame, it would have made a bunch of things easier for me. :-)
Aw, c'mon now. If things w
On Tue, May 29, 2012 at 5:25 PM, Mark Murphy wrote:
> On Tue, May 29, 2012 at 11:19 AM, Latimerius
> wrote:
>> I don't know...I thought of this but I wasn't able to confirm it. A
>> can access files after B's uninstallation that were never read or even
>> opened before B's uninstallation. Unli
On Tue, May 29, 2012 at 5:24 PM, Marcin Orlowski
wrote:
>
> Weren't these files A's assets? If so, the were in A's .apk file, so even
> you uninstall or remove (rm) that file, filesystem still got it unless all
> handles refering to it are closed. That's how linux fs works.
Nope, that's what make
On Tue, May 29, 2012 at 11:19 AM, Latimerius wrote:
> I don't know...I thought of this but I wasn't able to confirm it. A
> can access files after B's uninstallation that were never read or even
> opened before B's uninstallation. Unlike the test, in the actual app
> where I bumped into this, B
On 29 May 2012 17:19, Latimerius wrote:
> On Tue, May 29, 2012 at 4:37 PM, Kostya Vasilyev
> wrote:
> > The assets of package B are probably open and memory mapped by package
> A's
> > process.
>
> I don't know...I thought of this but I wasn't able to confirm it. A
> can access files after B's
On Tue, May 29, 2012 at 4:37 PM, Kostya Vasilyev wrote:
> The assets of package B are probably open and memory mapped by package A's
> process.
I don't know...I thought of this but I wasn't able to confirm it. A
can access files after B's uninstallation that were never read or even
opened before
The assets of package B are probably open and memory mapped by package A's
process.
(actually, it's more likely that the .apk file is open, and the part that
contains assets and resources is memory mapped).
If so, the behavior is not surprising.
-- K
2012/5/29 Latimerius
> On Tue, May 29, 201
On Tue, May 29, 2012 at 11:41 AM, Latimerius wrote:
>
> Fair enough - thanks anyway. I'll try to verify my results in the
> meantime.
I have a fairly minimal test setup with pkgB which is just a file in
assets/ and pkgA which has just enough code get pkgB's Context on
startup, listen to broadcas
On Tue, May 29, 2012 at 10:01 AM, TreKing wrote:
> On Tue, May 29, 2012 at 2:15 AM, Latimerius
> wrote:
>>
>> However the puzzling part is that A seems to be able to access (read
>> and use) *files* in B's assets/ directory. If B's gone those should
>> be gone too - right?
>
>
> Well, that's int
On Tue, May 29, 2012 at 2:15 AM, Latimerius wrote:
> However the puzzling part is that A seems to be able to access (read
> and use) *files* in B's assets/ directory. If B's gone those should
> be gone too - right?
>
Well, that's interesting. Don't know what to tell you about. I was mostly
makin
On Tue, May 29, 2012 at 1:19 AM, TreKing wrote:
> On Mon, May 28, 2012 at 3:10 PM, Latimerius
> wrote:
>>
>> Say package A gets a package B's Context by calling
>>
>> Context pkgBctx = createPackageContext ("B", 0);
>
>
> Read the summary for that method.
Cheers for the hint but I know that by h
On Mon, May 28, 2012 at 3:10 PM, Latimerius wrote:
> Say package A gets a package B's Context by calling
>
> Context pkgBctx = createPackageContext ("B", 0);
>
Read the summary for that method. This is not "getting" package B's
Context. This is creating a Context that refers to that package. Cont
Say package A gets a package B's Context by calling
Context pkgBctx = createPackageContext ("B", 0);
While package A is holding on to and using pkgBctx, package B gets
uninstalled. What is supposed to happen then? According to my tests
and much to my surprise, package A seems to be able to use
20 matches
Mail list logo
