commit 56cd97e73e88698cf9c0069c6e64587b871b3524
author Marijn Kruisselbrink <mek@chromium.org> Thu Sep 24 03:26:04 2020
committer Commit Bot <commit-bot@chromium.org> Thu Sep 24 03:26:04 2020
tree 3c1d88790b4d2d79b647942fff66dd3cb9072aa8
parent b9f14c9fd8d877e01033777f1571f89774ca3ec8

Make the Native File System API work with special volumes on Chrome OS.

At a high level, this enables creating handles from either local paths
or external paths. An external path is a path that can be used as
virtual path in a kFileSystemTypeExternal file system URL. These
external paths are intentionally not wrapped in an isolated file system,
as doing so would make it much harder to keep track of this virtual path,
and we need the virtual path to be able to serialize these handles to
IndexedDB.

(local paths are still wrapped in an isolated file system, although some
of the previous CLs that enabled not using one in this case has made
that no longer needed either. In the future I hope to be able to
eliminate/replace isolated file systems entirely).

This adds a PathType enum/parameter to CreateFile/DirectoryEntryFromPath
methods in NFSEntryFactory/NFSManagerImpl. This parameter makes it clear
if the path is a local path or an external path.

And changes the result FileSystemChooser returns from simply being a
base::FilePath to being a combination of a FilePath and a PathType.
This is then used by NFSManagerImpl to create the right type of
FileSystemURL/entry.

Currently all the permissions code still just deals with raw
base::FilePaths without indication if a path is a virtual/external or
local path. This shouldn't matter, since on ChromeOS (the only place
we use external paths) these paths will never overlap anyway, but we
might want to revisit this in the future.

This could have been implemented by having FileSystemChooser return the
appropriate FileSystemURL directly (and changing the NFSEntryFactory API
to be in terms of FileSystemURL); that was not done because in my ideal
end state FileSystemURL wouldn't be used anywhere in the native file
system code. I.e. it would purely be an implementation detail, but the
interface between the native file system code and file system backends
wouldn't depend on it anymore. Still working out the details for that.

Bug: 1093653
Change-Id: I201703d427a5368e67b0410428f366d1dca91aa8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2354596
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Luciano Pacheco <lucmult@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#810080}