预检清单
- 我已阅读了此项目的 Contributing Guidelines。
- 我同意遵循此项目遵循的 Code of Conduct。
- 我在 issue tracker 中搜索了一个与我想提交的功能请求相匹配的功能请求，但没有成功。
问题描述
在 Electron 环境中，File 接口通过一个包含实际文件系统路径的 path 属性进行了扩展。
目前，File System Access API 返回的文件或目录句柄没有等效项。
此外，由 FileSystemFileHandle.getFile 返回的 File 具有空的 path。
建议的解决方案
- 在
FileSystemHandle接口中添加一个包含实际文件系统路径的path属性 - 确保由 FileSystemFileHandle.getFile 返回的
File上的path属性被填充。
考虑的其他方案
在 Electron 环境中使用 node 的 fs 模块是一种完全可行的方法。
缺点是对于在 web 和 electron 之间共享代码的应用程序，复杂性会增加。
其他信息
参见：
4条答案
按热度按时间j13ufse21#
我尝试将这个patch应用到官方的最新版本的CEF上，并在我的演示中进行测试。可以在
window.showOpenFilePicker上重现。这可能是由Chromium引起的吗？ljo96ir52#
此外，由 FileSystemFileHandle.getFile 返回的
File具有空的path。我们在从 File 切换到 FileSystem*Handle API 进行一些文件交互后，也遇到了这个问题。
@zcbenz 看起来你是
blink_file_path.patch的原始作者，该属性添加了File.path。你是否知道将此功能添加到 FileSystemFileHandle 中可能会有多困难？lokaqttq3#
我尝试过实现这个：$x_{1e0f1}x$
肯定需要从电子维护者那里得到一些建议，但至少这表明这是可能的！
ngynwnxp4#
我也非常需要这个。我使用文件系统API实现了所有文件逻辑(对我来说，我也比通过ipc + fs模块进行文件操作获得了更好的性能),但现在我陷入了困境，因为没有办法找到使用文件系统API创建/读取的文件或文件夹的真实路径：(