Until now, access checks were tied to a "file system entry". As of #96, a "file system entry" corresponds to an actual file or directory on disk. We need to support access checks on FileSystemHandles which don't correspond to an entry (e.g. the entry has been removed), so the access checks must be tied to something else.
This PR gives each FileSystemHandle a "permission root locator". A newly created child FileSystemHandle will inherit this attribute from its parent (as opposed to its access algorithms), such that if subDir was created from rootDir, subDir.requestPermission() is equivalent to rootDir.requestPermission(). This "permission root locator" is serialized, such that storing a handle in IDB now retains information about where the handle originated from
Until now, access checks were tied to a "file system entry". As of #96, a "file system entry" corresponds to an actual file or directory on disk. We need to support access checks on FileSystemHandles which don't correspond to an entry (e.g. the entry has been removed), so the access checks must be tied to something else.
This PR gives each
FileSystemHandle
a "permission root locator". A newly created childFileSystemHandle
will inherit this attribute from its parent (as opposed to its access algorithms), such that ifsubDir
was created fromrootDir
,subDir.requestPermission()
is equivalent torootDir.requestPermission()
. This "permission root locator" is serialized, such that storing a handle in IDB now retains information about where the handle originated fromThe new "query access" and one "request access" algorithms are expected to be overridden in https://wicg.github.io/file-system-access/#permissions to handle non-BucketFileSystem use cases.
Fixes #101
Preview | Diff