cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: [file plugin] Accessing physical device paths
Date Fri, 28 Feb 2014 19:53:57 GMT
Note to anyone reading this guide in the future: I think it is still not
advisable to store or consume the result of "entry.toNativeURL()" in a way
that your app depends on being stable.  You should store the original path
passed to getFile() etc only, and resolve toNativeURL() only at the time of
use with each run of the application.


On Fri, Feb 28, 2014 at 1:01 PM, Ian Clelland <>wrote:

> Hi Anthony,
> I'm glad to hear your feedback on this. I've been the principal dev behind
> this refactoring, and I suppose I've been responsible for a lot of these
> sorts of decisions (although not entirely; the mailing list is littered
> with long long threads about File and associated plugins)
> The original reason for hiding this was to try to enforce the idea that
> HTML filesystems are supposed to be sandboxed. In Chrome, for instance,
> there is no way for a web site or app, even with filesystem permissions, to
> get the actual on-disk location of any of your files, even given a
> FileEntry object for them. It's simply none of the app's business where the
> files actually live.
> From a security perspective, I had always believed that it is better not to
> expose those kinds of details to JavaScript code. Partly because the app
> shouldn't care, and partly because it opens up possibilities for apps to
> read and write to locations that they really shouldn't have access to.
> This abstraction also gives us the flexibility to introduce new types of
> filesystems, where the resources may not even be files in the traditional
> sense. Having them all under the "cdvfile" URL scheme means a single code
> path can can be the entry point into the file plugin, and there's (ideally)
> only one place to deal with these URLs.
> Having said all that, I can appreciate your position here. The abstraction
> isn't perfect, and there are places where, when dealing with the iOS or
> Android webviews, it falls apart.
> The very earliest dev releases of the refactored File plugin didn't even
> have _getLocalFileSystemPath -- I didn't add that until I had actually
> pushed it to git and started to use it with other plugins, like
> FileTransfer. At that point, it was clear that some at least that plugin
> would need a way to get an actual file path, given a cdvfile URL. So that
> method was added, and marked as just for the use of FileTransfer.
> Since releasing 1.0.0, we have had a lot more feedback about how other
> plugins interact with File, and how people are using filesystem URLs in
> their apps, and what's not working like it used to. I've made some biggish
> changes to the plugin to address this feedback; hopefully it addresses your
> issues as well.
> The first big change since 1.0.0 was released was to make an explicit
> interface for native code to convert between cdvfile URLs and absolute
> device filesystem paths. This was CB-6057, and there is a document now that
> plugin authors can use for guidance on working with the new URLs. This was
> done still with the intention that, while native code might need to work
> with filesystem paths, we should still keep those methods away from the
> JavaScript code in the app.
> (Incidentally, the first customer of this API was the zip plugin itself --
> v2.0.0 at uses this, and works
> well
> with File 1.0.1.)
> The second change was spurred by CB-6079, and implemented as CB-6106. It
> turns out, as you've noticed, that there are some places in the webview
> which simply cannot use URLs with schemes other than file:// and http[s].
> The <audio> and <video> tags, specifically, just cannot be made to work
> with cdvfile:// URLs, and I suspect that there are other cases as well.
> (Even <img> tags, before Android 4.0.0, have troubles with these URLs.)
> To address that, there is a new method on FileEntry objects,
> FileEntry.toNativeURL(), which provides a URL which *can* be used for
> these, and which I suspect can be used in your case as well, rather than
> calling the exec bridge.
> As soon as the new version is released, you should be able to replace any
> instances of your exec() call with "entry.toNativeURL()", and get back a
> URL which you can use.
> I think it's unfortunate that we have to expose device-path locations in
> this way; it's an information leak at the very least, and it means that we
> need to be extra careful that paths which should be unavailable to the app
> actually *are* off-limits, but it appears to be a necessity.
> Hopefully these changes address your concerns -- I certainly want the new
> version of File to be at least as useful as the previous version. If you
> think that more still needs to be done, please email me (or the list); I'd
> love to talk about your use cases.
> Regards,
> Ian
> On Fri, Feb 28, 2014 at 11:22 AM, Anthony Rumsey <>
> wrote:
> > Hi there Cordova devs!
> >
> > The release of version 1.0 of the file plugin obviously changed the
> > behaviour of a majority of its API in order to be better aligned with the
> > W3C file spec.  As an app developer at Adobe and user of this plugin the
> > abstraction of device paths to filesystem URLs is great in order to get
> > consistent behaviour across devices.  On the other hand there are cases
> > when a lament the loss of having access to actual device paths.  Is it
> not
> > possible to to have the best opt both worlds and allow the file plugin to
> > convert file entry URLs to local paths when desired?
> >
> > Wait a second! There is an internal method already that provides
> > thisÅ "_getLocalFilesystemPath"!!
> >
> > I know there has been lengthy discussion on this topic in the past but
> > what was the final reason for hiding this functionality?
> >
> > Now for some context on my use case.
> >
> > In the process of upgrading an app I'm working on to use file-plugin 1.0
> I
> > ran across 2 cases where I needed an actual local filesystem path.
>  First,
> > the app downloads ZIP files from a server and then unzips them on the
> > device to persistent storage. The zip plugin in this case expects local
> > file system paths as its source and destination.  Maybe the solution to
> > this usage would be for the zip plugin to support filesystem URLs.  Fair
> > enough but that isn't the case today.  Second, once the zip content is
> > stored I then want to redirect my web view to that location.  With the
> > testing I did there didn't seem to be a way to redirect to a filesystem
> > URL using 'window.location.href'.
> >
> > In both cases, since '_getLocalFilesystemPath' exists, I have resorted to
> > calling 'window.cordova.exec(success, fail, "File",
> > "_getLocalFilesystemPath", [url]);' in order to get the desired path.
> >
> > Thanks,
> > Anthony
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message