Basic concepts of File system APIs

The FileSystem API (file system API) simulates a local file system that a network application can navigate to. You can develop applications to read, write, create, and index files in a sandbox virtual file system.

The file system API interacts with other related APIs. It is based on the file write API (the files writer API), and the latter is based on the file API (FileName API). Each API has a different function. These APIs are a huge evolutionary leap forward for web applications, enabling them to cache and process large volumes of data.

About this document edit

This article discusses the basic concepts and terminology in the file system API. It will give you a general Blueprint and guide you to understand the key concepts. It also describes some limitations, and if you ignore them the amount can generate a security error. See the definition section for more terms used in the API.

For a reference section of the file system API, view the referenced landing page and its sub-pages.

The specification is still in the definition and may change.

Overview Edit

The file system API consists of both asynchronous and synchronous interfaces. Asynchronous APIs can be applied when you don't want to manipulate the lock UI. On the other hand, the synchronization API allows a simple program model, but it must be used in conjunction with Webworkers.

The purpose of the API

The importance of file system APIs is reflected in the following areas:

• It allows applications to have offline and stored attributes that involve binary large objects (BLOBs).
• It optimizes the performance of your application by prefetching resources in the background and caching locally.
• It enables users of your Web application to directly edit binaries in the local file directory.
• It provides a storage API that your users are already familiar with, just as they are accustomed to file systems.

For an example of the features you can create with this API , see the Examples section.

File system APIs and other storage APIs

File system APIs are other storage APIs, such as IndexedDB, websql (deprecated on September 18, 2010), and alternatives such as AppCache. The API is a better choice for applications that handle blobs because:

• The File System API provides client-side storage to address scenarios that are not stored in the database. If you need a large, variable block of data, it is a more efficient storage solution than a database.
• Although Firefox supports INDEXEDDB blob storage, this is not the case with chrome (chrome is still in development support for INDEXEDDB BLOB storage). If your app is for chrome and you need to store blobs, then the file system API and app cache will be your only option. However, AppCache storage is not locally mutable, and fine-grained client management is not supported.
• In Chrome, you can use the file system API and the quota management API Quota Management API, which allows you to request more storage and manage your storage quotas.

Example Usage scenarios

Here are a few examples of how you can use the File system API:

• Application with uploader
  • When you select a file or directory to upload, you can assign a file to a local Shahe and upload one block at a time.
  • Apps can be re-uploaded after an outage, which could include a browser being shut down or crashing, a connection being interrupted, or a computer being shut down.
• Video games or other apps that use a lot of media resources
  • The app downloads one or more large compressed packages and extracts them locally to a file directory.
  • Apps can prefetch resources in the background, allowing users to move to the next job or game level without waiting for the download to take.
• Audio or photo Editor uses offline access or local cache (helps with performance and speed)
  • Apps can write to files in segments (such as overwriting only id3/exif tags instead of the entire file).
• Offline Video Browsing
  • Apps can download large files (>1GB) for later browsing.
  • The app can access only the portions of the file (so you can view the first chapter of your DVD, even if the app is still downloading the rest, or when you need to catch a train without completing the download).
• Offline Network mail client
  • The client downloads the attachments and stores them locally.
  • Client-side cache attachments are used for later uploads.

Main concept Edit

Before you start using the file system APIs, you need to understand several concepts:

• File System API is a virtual representation of a file system
• File system APIs can use different storage types
• Quotas for browser-qualified storage
• The file system API has two versions of asynchronous and synchronous
• When using asynchronous APIs, be sure to use the error callback
• File system APIs interact with other APIs
• File system APIs are case sensitive

File System API is a virtual representation of a file system

The API does not allow you to access the local file system, which is not part of the file system. Instead, it is a virtual file system, which is like a mature file system for Web applications. It does not need to have any relationship with the local file system outside the browser.

This means that a Web application and a desktop app cannot share the same file at the same time. The API does not allow your web apps to be exposed to files from the browser, while desktop apps can. However, you can export a file from a Web application to a desktop app. For example, you can use the file API to create a blob, redirect an IFrame to point to the Blob, and invoke the download manager.

File system APIs can use different storage types

An app may require temporary or fixed storage. Temporary storage is relatively easy to obtain because the browser is already available, but it is restricted and may be deleted by the browser when the space is exhausted. On the other hand, fixed storage can provide you with more space and can only be deleted by the user, but it requires the user to obtain your permission.

Use temporary storage for caching, and use fixed storage to hold the data generated or unique by similar users that you want your app to save.

Quotas for browser-qualified storage

To prevent a network application from taking up the entire disk, the browser may limit quotas and allocate storage for each app.

How storage is allocated and how you can manage storage are features of the browser, so you need to consult your browser's respective documentation. For example, Google Chrome allows more than 5MB of temporary storage in the specification and supports the Quota management API. Learn more about Chrome's implementation and see Managing HTML5 offline storage.

The file system API has two versions of asynchronous and synchronous

The file system API has both asynchronous and synchronous versions. Both versions of the API provide the same functionality and features. In fact, they are basically the same, except for a few different points.

• webworkers. an asynchronous API can be used in a document or Webworkers Context, while the synchronization API can be used only for webworkers.
• callbacks. The asynchronous API does not use the data as the return value; instead, you need to pass a callback function. You send the request in the action and are notified when the callback occurs. Instead, the synchronization API does not use callback functions because the API method returns a value.
• Global methods for asynchronous and synchronous APIs . Asynchronous APIs have these global methods: requestFileSystem() and resolveLocalFileSystemURL() . These methods are also members of the Window object and the global scope of the worker. On the other hand, the synchronization API uses the following methods: requestFileSystemSync() and resolveLocalFileSystemSyncURL() . These synchronization methods are only members of the worker global scope, not the Window object.

The synchronization API may be simpler for some tasks. Its direct, sequential programming modules make the code easier to read. The disadvantage is that it must interact with the Web worker, which has some limitations.

When using asynchronous APIs, be sure to use the error callback

When using asynchronous APIs, it is important to always use error callbacks. Although error callbacks are optional parameters for related methods, it is wise to treat them as required. At the very least, you can know what happened by handling the error message that you got.

File system APIs interact with other APIs

The file system API is designed to interact with other APIs and elements on a network platform. For example, you might use one of the following:

• XMLHttpRequest (for example, send () methods that pass file and Blob objects)
• Drag & Drop API
• Web Workers (for synchronous version of file system APIs)
• inputElement (for programming from this element to get a list of files)

The File system API case-sensitive file system API is case-sensitive and preserves case.

Limit Edit

For security reasons, the browser imposes some restrictions on file access. If you ignore them, you will create a security error.

• File System API adheres to the same Origin policy
• File system API does not allow creation or renaming of executable files
• The file system is sandboxed.
• You can't run your app through file://.

File System API adheres to the same Origin policy

A source is the domain where the script executes the URL of the document, the Application layer protocol, and the port. Each source has its own set of file systems associated with it

Security restrictions made on the file system prevent the app from accessing data from different sources. This protects the private data from being accessed or deleted. For example, when an app or page is on a http://www.example.com/app/, it can access files located on http://www.example.com/dir/because they have the same source, and it cannot be located at/http www.example.com:8080/dir/ (different ports) or https://www.example.com/dir/ (different protocols) on the file.

File system API does not allow creation or renaming of executable files

To prevent malicious apps from running executable files, you cannot create executables in the sandbox of the file system API.

The file system is sandboxed.

Because the file system is sandboxed, one network application cannot access another application's files. You also cannot read and write files in any folder on the user's hard disk.

You can't run your app through file://.

You can't run your app locally through file://. If you do that, the browser throws an error, or your app will silently fail. This limitation also applies to many other file APIs, including Blobbuilder and FileReader.

For testing purposes, you can do this in chrome by adding--allow-file-access-from-files参数来绕开这一限制，这一参数仅用于这个目的。

Define Edit

This section defines and explains the terminology used in the file system APIs.

Blob

Represents a binary large object. A blob is a set of binary data stored in a single object. This is a common method of referencing binary data in a network application. A blob can be a picture or an audio file.

Blob

BLOBs (beginning with uppercase B) are immutable data structures, which means that a BLOB reference binary data cannot be directly modified. This makes their behavior predictable when blobs is passed into the asynchronous API.

Persistent Storage | fixed storage

Fixed storage is a medium-term storage that exists in the browser unless the user permanently deletes it or the app deletes it.

Temporary Storage | Temporary storage

temporary storage is owned by any network application. It is automatic and does not require a request, but the browser can delete the storage without any warning.

Basic concepts of File system APIs