Fix/redirect some links in “File and Directory Entries API” intro (mdn#7572)

sideshowbarker · web-flow · commit 2d23975eb8cb · 2021-08-04T07:45:35.000+02:00
Fixes mdn#7569
diff --git a/files/en-us/_redirects.txt b/files/en-us/_redirects.txt
@@ -8917,6 +8917,7 @@
 /en-US/docs/Web/API/Window/onvrdisplayconnected	/en-US/docs/Web/API/Window/onvrdisplayconnect
 /en-US/docs/Web/API/Window/onvrdisplaydisconnected	/en-US/docs/Web/API/Window/onvrdisplaydisconnect
 /en-US/docs/Web/API/Window/removeEventListener	/en-US/docs/Web/API/EventTarget/removeEventListener
+/en-US/docs/Web/API/Window/resolveLocalFileSystemURL	/en-US/docs/Web/API/LocalFileSystem#resolvelocalfilesystemurl()
 /en-US/docs/Web/API/Window/restore	/en-US/docs/Web/API/Window/moveTo
 /en-US/docs/Web/API/Window/setInterval	/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval
 /en-US/docs/Web/API/Window/setTimeout	/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout
@@ -8982,6 +8983,7 @@
 /en-US/docs/Web/API/WorkerGlobalScope/fetch	/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
 /en-US/docs/Web/API/WorkerGlobalScope/indexedDB	/en-US/docs/Web/API/WindowOrWorkerGlobalScope/indexedDB
 /en-US/docs/Web/API/WorkerGlobalScope/onclose	/en-US/docs/Web/API/DedicatedWorkerGlobalScope/close
+/en-US/docs/Web/API/WorkerGlobalScope/requestFileSystemSync	/en-US/docs/Web/API/LocalFileSystemSync/requestFileSystemSync
 /en-US/docs/Web/API/WorkerGlobalScope/setInterval	/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval
 /en-US/docs/Web/API/WorkerGlobalScope/setTimeout	/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout
 /en-US/docs/Web/API/WorkerLocation.hash	/en-US/docs/Web/API/WorkerLocation/hash
diff --git a/files/en-us/web/api/file_and_directory_entries_api/introduction/index.html b/files/en-us/web/api/file_and_directory_entries_api/introduction/index.html
@@ -27,7 +27,7 @@ <h2 id="About_this_document">About this document</h2>
 
 <h2 id="Overview">Overview</h2>
 
-<p>The File and Directory Entries API includes both <a href="/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction#asynchronous_apis">asynchronous</a> and <a href="/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction#synchronous_apis">synchronous</a> versions of the interfaces. The asynchronous API can be used in cases where you don't want an outstanding operation to block the UI. The synchronous API, on the other hand, allows for simpler programming model, but it must be used with <a href="/en-US/docs/Web/API/Web_Workers_API/Using_web_workers">WebWorkers</a>. </p>
+<p>The File and Directory Entries API includes both <a href="#asynchronous_apis">asynchronous</a> and <a href="#synchronous_apis">synchronous</a> versions of the interfaces. The asynchronous API can be used in cases where you don't want an outstanding operation to block the UI. The synchronous API, on the other hand, allows for simpler programming model, but it must be used with <a href="/en-US/docs/Web/API/Web_Workers_API/Using_web_workers">WebWorkers</a>. </p>
 
 <h3 id="Usefulness_of_the_API">Usefulness of the API</h3>
 
@@ -49,7 +49,7 @@ <h3 id="The_File_and_Directory_Entries_API_and_other_storage_APIs">The File and
 <ul>
  <li>The File and Directory Entries API offers client-side storage for use cases that are not addressed by databases. If you want to have large mutable chunks of data, the File and Directory Entries API is a much more efficient storage solution than a database.</li>
  <li>While Firefox supports blob storage for IndexedDB, Chrome currently does not (Chrome is still implementing support for blob storage in IndexedDB). If you are targeting Chrome for your app and you want to store blobs, the File and Directory Entries API and App Cache are your only choices. However, AppCache storage isn't locally mutable, and doesn't allow for fine-grained client-side management.</li>
- <li>In Chrome, you can use the File and Directory Entries API with the <a href="http://code.google.com/chrome/whitepapers/storage.html">Quota Management API</a>, which lets you ask for more storage and manage your storage quota. </li>
+ <li>In Chrome, you can use the File and Directory Entries API with the <a href="https://code.google.com/chrome/whitepapers/storage.html">Quota Management API</a>, which lets you ask for more storage and manage your storage quota. </li>
 </ul>
 
 <h3 id="sample">Sample use cases</h3>
@@ -118,7 +118,7 @@ <h3 id="quota">Browsers impose storage quotas</h3>
 
 <p>To prevent a web app from using up the entire disk, browsers might impose a quota for each app and allocate storage among web apps.</p>
 
-<p>How storage space is granted or allocated and how you can manage storage are idiosyncratic to the browser, so you need to check the respective documentation of the browser. Google Chrome, for example, allows temporary storage beyond the 5 MB required in the specifications and supports the Quota Management API. To learn more about the Chrome-specific implementation, see <a href="http://code.google.com/chrome/whitepapers/storage.html">Managing HTML5 Offline Storage</a>.</p>
+<p>How storage space is granted or allocated and how you can manage storage are idiosyncratic to the browser, so you need to check the respective documentation of the browser. Google Chrome, for example, allows temporary storage beyond the 5 MB required in the specifications and supports the Quota Management API. To learn more about the Chrome-specific implementation, see <a href="https://code.google.com/chrome/whitepapers/storage.html">Managing HTML5 Offline Storage</a>.</p>
 
 <h3 id="version">The File and Directory Entries API has asynchronous and synchronous versions</h3>
 
@@ -166,7 +166,7 @@ <h3 id="origin">The File and Directory Entries API adheres to the same-origin po
 
 <p>An origin is the domain, application layer protocol, and port of a URL of the document where the script is being executed. Each origin has its own associated set of file systems.</p>
 
-<p>The security boundary imposed on file system prevents applications from accessing data with a different origin. This protects private data by preventing access and deletion. For example, while an app or a page in <a href="http://www.example.com/app/" rel="external">http://www.example.com/app/</a> can access files from <a href="http://www.example.com/dir/" rel="external">http://www.example.com/dir/</a>, because they have the same origin, it cannot retrieve files from <a href="http://www.example.com:8080/dir/" rel="external">http://www.example.com:8080/dir/</a> (different port) or <a href="https://www.example.com/dir/" rel="external">https://www.example.com/dir/</a> (different protocol).</p>
+<p>The security boundary imposed on file system prevents applications from accessing data with a different origin. This protects private data by preventing access and deletion. For example, while an app or a page in <a href="https://www.example.com/app/" rel="external">http://www.example.com/app/</a> can access files from <a href="https://www.example.com/dir/" rel="external">http://www.example.com/dir/</a>, because they have the same origin, it cannot retrieve files from <a href="https://www.example.com:8080/dir/" rel="external">http://www.example.com:8080/dir/</a> (different port) or <a href="https://www.example.com/dir/" rel="external">https://www.example.com/dir/</a> (different protocol).</p>
 
 <h3 id="execute">The File and Directory Entries API does not let you create and rename executable files</h3>
 
@@ -232,5 +232,5 @@ <h2 id="See_also">See also</h2>
 
 <ul>
  <li><a href="/en-US/docs/Web/API/File_and_Directory_Entries_API">File and Directory Entries API</a></li>
- <li><a href="http://www.html5rocks.com/en/tutorials/file/filesystem/">Exploring the FileSystem APIs</a> (HTML5 Rocks)</li>
+ <li><a href="https://www.html5rocks.com/en/tutorials/file/filesystem/">Exploring the FileSystem APIs</a> (HTML5 Rocks)</li>
 </ul>
