This plugin provides the HTML5 Filesystem API. For usage, refer to HTML5 Rocks' FileSystem article on the subject. For an overview of other storage options, refer to Cordova's storage guide.
cordova plugin add org.apache.cordova.file
* These platforms do not support FileReader.readAsArrayBuffer nor FileWriter.write(blob).
As of v1.2.0, URLs to important file-system directories are provided. Each URL is in the form file:///path/to/spot/, and can be converted to a DirectoryEntry using window.resolveLocalFileSystemURL().
cordova.file.applicationDirectory - Read-only directory where the application is installed. (iOS, Android)
cordova.file.applicationStorageDirectory - Root of app's private writable storage. (iOS, Android)
cordova.file.dataDirectory - Where to put app-specific data files. (iOS, Android)
cordova.file.cacheDirectory - Cached files that should survive app restarts. Apps should not rely on the OS to delete files in here. (iOS, Android)
cordova.file.externalApplicationStorageDirectory - Application space on external storage. (iOS, Android)
cordova.file.externalDataDirectory - Where to put app-specific data files on external storage. (Android)
cordova.file.externalCacheDirectory - Application cache on external storage. (Android)
cordova.file.externalRootDirectory - External storage (SD card) root. (Android)
cordova.file.tempDirectory - Temp directory that the OS can clear at will. (iOS)
cordova.file.syncedDataDirectory - Holds app-specific files that should be synced (e.g. to iCloud). (iOS)
cordova.file.documentsDirectory - Files private to the app, but that are meaningful to other applciations (e.g. Office files). (iOS)
There are multiple valid locations to store persistent files on an Android device. See this page for an extensive discussion of the various possibilities.
Previous versions of the plugin would choose the location of the temporary and persistent files on startup, based on whether the device claimed that the SD Card (or equivalent storage partition) was mounted. If the SD Card was mounted, or if a large internal storage partition was available (such as on Nexus devices,) then the persistent files would be stored in the root of that space. This meant that all Cordova apps could see all of the files available on the card.
If the SD card was not available, then previous versions would store data under /data/data/, which isolates apps from each other, but may still cause data to be shared between users.
It is now possible to choose whether to store files in the internal file storage location, or using the previous logic, with a preference in your application's config.xml file. To do this, add one of these two lines to config.xml:
<preference name="AndroidPersistentFileLocation" value="Internal" /> <preference name="AndroidPersistentFileLocation" value="Compatibility" />
Without this line, the File plugin will use “Compatibility” as the default. If a preference tag is present, and is not one of these values, the application will not start.
If your application has previously been shipped to users, using an older (pre- 1.0) version of this plugin, and has stored files in the persistent filesystem, then you should set the preference to “Compatibility”. Switching the location to “Internal” would mean that existing users who upgrade their application may be unable to access their previously-stored files, depending on their device.
If your application is new, or has never previously stored files in the persistent filesystem, then the “internal” setting is generally recommended.
FileReader.readAsText(blob, encoding)encoding parameter is not supported, and UTF-8 encoding is always in effect.There are two valid locations to store persistent files on an iOS device: the Documents directory and the Library directory. Previous versions of the plugin only ever stored persistent files in the Documents directory. This had the side-effect of making all of an application's files visible in iTunes, which was often unintended, especially for applications which handle lots of small files, rather than producing complete documents for export, which is the intended purpose of the directory.
It is now possible to choose whether to store files in the documents or library directory, with a preference in your application's config.xml file. To do this, add one of these two lines to config.xml:
<preference name="iosPersistentFileLocation" value="Library" /> <preference name="iosPersistentFileLocation" value="Compatibility" />
Without this line, the File plugin will use “Compatibility” as the default. If a preference tag is present, and is not one of these values, the application will not start.
If your application has previously been shipped to users, using an older (pre- 1.0) version of this plugin, and has stored files in the persistent filesystem, then you should set the preference to “Compatibility”. Switching the location to “Library” would mean that existing users who upgrade their application would be unable to access their previously-stored files.
If your application is new, or has never previously stored files in the persistent filesystem, then the “Library” setting is generally recommended.
The File System API is not natively supported by Firefox OS and is implemented as a shim on top of indexedDB.
requestAllFileSystems and resolveLocalFileSystemURI methodscopyTo and moveTo do not support directoriesIn v1.0.0 of this plugin, the FileEntry and DirectoryEntry structures have changed, to be more in line with the published specification.
Previous (pre-1.0.0) versions of the plugin stored the device-absolute-file-location in the fullPath property of Entry objects. These paths would typically look like
/var/mobile/Applications/<application UUID>/Documents/path/to/file (iOS) /storage/emulated/0/path/to/file (Android)
These paths were also returned by the toURL() method of the Entry objects.
With v1.0.0, the fullPath attribute is the path to the file, relative to the root of the HTML filesystem. So, the above paths would now both be represented by a FileEntry object with a fullPath of
/path/to/file
If your application works with device-absolute-paths, and you previously retrieved those paths through the fullPath property of Entry objects, then you should update your code to use entry.toURL() instead.
For backwards compatibility, the resolveLocalFileSystemURL() method will accept a device-absolute-path, and will return an Entry object corresponding to it, as long as that file exists within either the TEMPORARY or PERSISTENT filesystems.
This has particularly been an issue with the File-Transfer plugin, which previously used device-absolute-paths (and can still accept them). It has been updated to work correctly with FileSystem URLs, so replacing entry.fullPath with entry.toURL() should resolve any issues getting that plugin to work with files on the device.
In v1.1.0 the return value of toURL() was changed (see [CB-6394] (https://issues.apache.org/jira/browse/CB-6394)) to return an absolute ‘file://’ URL. wherever possible. To ensure a ‘cdvfile:’-URL you can use toInternalURL() now. This method will now return filesystem URLs of the form
cdvfile://localhost/persistent/path/to/file
which can be used to identify the file uniquely.
When an error is thrown, one of the following codes will be used.
The set of available filesystems can be configured per-platform. Both iOS and Android recognize a tag in config.xml which names the filesystems to be installed. By default, all file-system roots are enabled.
<preference name="iosExtraFilesystems" value="library,library-nosync,documents,documents-nosync,cache,bundle,root" /> <preference name="AndroidExtraFilesystems" value="files,files-external,documents,sdcard,cache,cache-external,root" />
android.permission.WRITE_EXTERNAL_STORAGE permission to use this.Android also supports a special filesystem named “documents”, which represents a “/Documents/” subdirectory within the “files” filesystem.
By default, the library and documents directories can be synced to iCloud. You can also request two additional filesystems, “library-nosync” and “documents-nosync”, which represent a special non-synced directory within the Library or Documents filesystem.