You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Git at Apache <gi...@git.apache.org> on 2012/07/09 23:31:31 UTC
incubator-cordova-mobile-spec pull request: Changed file and all autotest p...
GitHub user filmaj opened a pull request:
https://github.com/apache/incubator-cordova-mobile-spec/pull/8
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 https://github.com/filmaj/incubator-cordova-mobile-spec ripple
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-cordova-mobile-spec/pull/8.patch
----
commit 62c284c77a0d9045a0ec1ac5730cee595a029c44
Author: Fil Maj <ma...@gmail.com>
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?)
----
Re: incubator-cordova-mobile-spec pull request: Changed file and all
autotest p...
Posted by Brian LeRoux <b...@brian.io>.
post 2.x either way --- think this will flow from the 'revisit all the apis'
On Tue, Jul 10, 2012 at 5:59 AM, Simon MacDonald
<si...@gmail.com> wrote:
> On Tue, Jul 10, 2012 at 1:59 AM, Filip Maj <fi...@adobe.com> wrote:
>>
>> 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.
>
> Yup, I don't disagree and didn't disagree back when we started talking
> about this on the mailing list back in February.
>
> https://mail-archives.apache.org/mod_mbox/incubator-callback-dev/201202.mbox/%3CCAM1AYQAKphbKQ7tkPNucM6EjEVa=N=cSDGiFjdoceMFbfvjnPw@mail.gmail.com%3E
>
> My only concern about the change is we need to let people know in
> plenty of time to change their application. There is even an open JIRA
> ticket on this https://issues.apache.org/jira/browse/CB-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
Re: incubator-cordova-mobile-spec pull request: Changed file and all
autotest p...
Posted by Simon MacDonald <si...@gmail.com>.
On Tue, Jul 10, 2012 at 1:59 AM, Filip Maj <fi...@adobe.com> wrote:
>
> 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.
Yup, I don't disagree and didn't disagree back when we started talking
about this on the mailing list back in February.
https://mail-archives.apache.org/mod_mbox/incubator-callback-dev/201202.mbox/%3CCAM1AYQAKphbKQ7tkPNucM6EjEVa=N=cSDGiFjdoceMFbfvjnPw@mail.gmail.com%3E
My only concern about the change is we need to let people know in
plenty of time to change their application. There is even an open JIRA
ticket on this https://issues.apache.org/jira/browse/CB-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
Simon Mac Donald
http://hi.im/simonmacdonald
Re: incubator-cordova-mobile-spec pull request: Changed file and all
autotest p...
Posted by Jesse MacFadyen <pu...@gmail.com>.
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
folders.
ie.
root
+ app
+ - www
+ temp
+ persistent
Cheers,
Jesse
Sent from my iPhone5 while walking the dog and not smoking.
On 2012-07-09, at 11:00 PM, Filip Maj <fi...@adobe.com> 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" <gi...@git.apache.org> wrote:
>
>> GitHub user filmaj opened a pull request:
>>
>> https://github.com/apache/incubator-cordova-mobile-spec/pull/8
>>
>> 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 https://github.com/filmaj/incubator-cordova-mobile-spec
>> ripple
>>
>> Alternatively you can review and apply these changes as the patch at:
>>
>> https://github.com/apache/incubator-cordova-mobile-spec/pull/8.patch
>>
>> ----
>> commit 62c284c77a0d9045a0ec1ac5730cee595a029c44
>> Author: Fil Maj <ma...@gmail.com>
>> 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?)
>>
>> ----
>
Re: incubator-cordova-mobile-spec pull request: Changed file and
all autotest p...
Posted by Filip Maj <fi...@adobe.com>.
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" <gi...@git.apache.org> wrote:
>GitHub user filmaj opened a pull request:
>
> https://github.com/apache/incubator-cordova-mobile-spec/pull/8
>
> 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 https://github.com/filmaj/incubator-cordova-mobile-spec
>ripple
>
>Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/incubator-cordova-mobile-spec/pull/8.patch
>
>----
>commit 62c284c77a0d9045a0ec1ac5730cee595a029c44
>Author: Fil Maj <ma...@gmail.com>
>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?)
>
>----
>