search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
665 stars 65 forks source link

[feat request] creating symbolic links #377

Closed jimmywarting closed 2 years ago

jimmywarting commented 2 years ago

It would be pretty sweet if you could create a symbolic link from a file or folder handle accessed from the picker and then put them into the sandboxed file system navigator.storage.getDirectory

you can also avoid having to copy over all the data from a user directory over to the sandboxed filesystem. or creating a IndexedDB and save this handles.

having this wold make working with both a user directory and sandboxed files more seamless together

const dir = await showDirectoryPicker()
const link = await dir.createSymbolicLink()
const root = await navigator.storage.getDirectory()
await root.addSymbolicLink(link)
a-sully commented 2 years ago

This is an interesting idea, but there are a few reasons I can think of why this might not be feasible:

  1. All web-modified files should have safe browsing checks run and the Mark-of-the-Web added to be saved to disk. Files written to the OPFS are not subject to these checks. Creating a symlink from a local file to a file in the OPFS would bypass these checks (see https://wicg.github.io/file-system-access/#security-malware)
  2. "there is no expectation that files or directories with names matching the names of children of the origin private file system exist" For example, the OPFS is entirely in-memory in private browsing mode. It would be impossible to create a symlink to these files (at least given the Chromium implementation)

I'm hopeful that we'll get move() landed soon, which will at least allow for more convenience across the local file system / OPFS boundary

rektide commented 2 years ago

@a-sully I'd like this to be re-opened.

  1. This seems like a specific operating system concern that could be easily amended. We shouldn't entirely disregard this ask because it's mildly inconvenient for one implementer. If we are going to say things like "Mark of the Web" obstruct this specification, there should be existing standards describing what Mark of the Web is, how it works, and have discussion forums open where we can bring up & get obstructions like this dealt with. Without a specification, it should not have any priority in shaping specifications, especially in blocking core capabilities.
  2. Even if there are no external user facing files (in my view, there very strongly ought to be, as this serves the user enormously, & the internet is for users): we should still be able to have symlinks, so we can do things like git checkout a repository & unpack it & work with it via FSA.

This is the only high performance file-system standard for the web platform, and it needs to be capable of working with what users have, which, in many cases will include symlinks.

jimmywarting commented 2 years ago

All web-modified files should have safe browsing checks run and the Mark-of-the-Web added to be saved to disk. Files written to the OPFS are not subject to these checks. Creating a symlink from a local file to a file in the OPFS would bypass these checks

What would stop us from just enable "safe browsing checks" on just some few file/folder/symbolic links parts in the OPFS? it would be no different than just saving it to the IndexedDB?

the hole OPFS can have safe-browsing check disabled by default but reading the content of an symbolic link saved in OPFS by a other picker would have safe-browsing check on on just this files