incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: incubator-cordova-mobile-spec pull request: Changed file and all autotest p...
Date Tue, 10 Jul 2012 05:59:44 GMT
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
>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