incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <>
Subject Re: incubator-cordova-mobile-spec pull request: Changed file and all autotest p...
Date Tue, 10 Jul 2012 06:41:07 GMT
iOS and WP7 are both sandboxed as well, but on wp7 we have to be
careful because the unpackaged app lives beside the temp/persistent

+ app
+ - www
+ temp
+ persistent


Sent from my iPhone5 while walking the dog and not smoking.

On 2012-07-09, at 11:00 PM, Filip Maj <> wrote:

> Just going to reiterate this pull request to our test suite, as I think
> it's important.
> Basically, the pull request adds cleanup routines before firing off the
> execution of any of the File API tests. The routine grabs the root
> FileSystem object returned via window.requestFileSystem (for both
> PERSISTENT & TEMPORARY types of file systems), lists off all the contents
> of these two FS's (directories + files), and deletes everything. This way
> we have a clean slate before running the tests. Especially important if
> you are re-running File tests that are failing (and whose post-test-run
> cleanup may not have executed).
> I came across this stuff adding up-to-date Cordova support to the Ripple
> emulator this weekend. It was a good exercise in that I had to code the
> browser-based equivalents to most of Cordova's APIs. In most cases,
> especially the File API, Ripple needs to marshall the exec() calls off to
> the underlying implementation.
> Example: exec calls to the "File" service + "write" action actually
> instantiates Chrome's implementation of a FileWriter, creates a Blob from
> a string, passes the blob into the FileWriter's write method, etc.
> Why do I bring this up with the list? Well, I need platform testing help,
> of course :). In actuality, I'm fearing that running the equivalent of "rm
> -rf ./*" under the root of the returned TEMPORARY and PERSISTENT file
> system directories via the Cordova APIs may be a bad idea. Like, does
> PERSISTENT/TEMPORARY return the equivalent of any shared file system space
> on any of our platforms (/sdcard on Android, or /Documents on iOS)?
> If so: we need to fix this. In Android and BlackBerry we have concepts of
> application sandboxes - our File APIs should use this space, that is,
> requestFileSystem should route to these safe, application-only spaces. I'm
> hoping iOS and Windows Phone 7 have a similar concept as well (and all of
> our other budding platforms, too). I would suggest that if application
> developers need to get at the device file system outside of these
> application jails or sandboxes (for example, shared spaces like /Documents
> or whatnot) to use window.resolveLocalFileSystemURI and pass in path
> strings that correlate to these shared spaces.
> One more note related to this pull request: I am probably going to have to
> patch a lot of our file tests this week at some point. There are a few
> assumptions in our tests related to the File API that are wrong. For
> example, that the TEMPORARY or PERSISTENT file system roots returned by
> the Cordova API have a path that is longer than just "/". In Chrome, the
> root file system path returned is always "/", so many tests failed :)
> On 7/9/12 5:31 PM, "Git at Apache" <> wrote:
>> GitHub user filmaj opened a pull request:
>>   Changed file and all autotest page bootup sequence
>>   The "all" and "file" autotest pages need a better cleanup sequence
>> before firing off the tests. I.e.: deleting everything in the PERSISTENT
>> and TEMPORARY folders before running the tests.
>>   Question for various platforms: is this safe to do? This would be a
>> standard thing to do in a web application. I am afraid that certain
>> platforms will give access to shared or otherwise sensitive file system
>> locations where basically running `rm -rf ./*` within the context of
>> those file systems would be a pretty stupid thing to do.
>>   If so: that should be fixed!
>> You can merge this pull request into a Git repository by running:
>>   $ git pull
>> ripple
>> Alternatively you can review and apply these changes as the patch at:
>> ----
>> commit 62c284c77a0d9045a0ec1ac5730cee595a029c44
>> Author: Fil Maj <>
>> Date:   2012-07-09T14:20:39-07:00
>>   Changed file and all autotest page bootup sequence. We need to clean
>> up the FileSystem before we can run tests (what if there are leftover
>> directories/files from a previous run?)
>> ----

View raw message