What is the storage of the File written using the HTML5 File API?

In HTML5, File API is added to allow programs to perform operations similar to local File systems. However, when you start to use the DEMO, you will have a question: what is the storage of the file? In the demo program, we set the File Creation Path to mongolog.txt. In theory, it will be created in the current file directory, but after the code prompts that the file is created successfully, we will find that the current directory does not have a txt file named log. Later I remembered the Javascript "sandbox". What is a sandbox? When javascript is running, there is a hidden danger: After a webpage is opened, javascript may execute a piece of harmful code on the computer, such as deleting word files in batches, or send these word files. To prevent this, javascript is designed to run only in the sandbox. A sandbox is a protected environment in which resources on a computer cannot be accessed. The browser's security policy defines what scripts can do and cannot do. Let's take a look at a section in the official document. Because this API may allow untrusted code to read and write parts of a user's hard drive, there are a number of security and privacy issues that must be dealt. risks to the user include: Denial of service by filling a local disk or using up IO bandwidth. this can be mitigated in part through quota limitations. theft or erasure of private data. this is mitigated by limiting the scope of access To the local filesystem to a chroot-like, origin-specific sandbox. storing malicious executables or illegal data on a user's system. this is similar to the risk of any download, and similar security precautions apply, but is potentially worse in that: It may involve multiple files. the files may be in a part of the filesystem that's harder for the user to find than the standard downloads directory. th E malicious writes may happen long enough after granting of filesystem access that the user doesn't connect the two events. this may be mitigated by restricting file creation/rename to non-executable extensions, virtualizing paths [leading to unguessable or non-executable filenames] and by making sure the execute bit is not set on any file created or modified via the API. as with any other client-si De storage, filesystem access allows for cookie-resurrection attacks. UAs will likely wish to present the option of clearing it when the user clears any other origin-specific storage, blocking access to it when cookies are blocked, etc. this is especially important if temporary storage space is permitted by default without explicit user permission. to ensure the security of the computer where the browser is located, the browser defines a series of security measures to reduce the running of scripts. Risks, including sandbox. When we call the file api through code, the browser will establish a simulated FILE System in a secure environment. All FILE read/write operations are performed in this secure environment. These generated files cannot be run out of the security zone through javascript code control, and the files outside the security zone cannot be run in. With these policies, the program is much more secure when using the file api. We can find the file we created in the directory below: C: \ Users \ {username} \ AppData \ Local \ Google \ Chrome \ User Data \ Default \ File System \ 000 \ t \ 00 in this directory, the file name is not the name we specify, but the eight-digit representation generated by the browser. The first generated file name is 00000000. It has no suffix and can be opened in the notepad ++ editor. The second is 00000001, and so on.