HTML5 文件系统 API：如果文件在 API 之外被删除，则无法使用 getFile()
我在 Chrome 扩展程序中使用 HTML5 FileSystem API。
有一种不太可能（但可能）的情况：
- 使用
fileWriter.write()创建文件 - 用户导航到其 Chrome 用户数据文件夹 > >文件系统文件夹，并删除创建的文件（使用其操作系统，不使用 FileSystem API）
- 此文件的所有未来调用
getFile()都会触发FileError.NOT_FOUND_ERR在错误处理程序中。
看来，如果在 FileSystem API 之外删除文件，getFile() 总是会出现该文件的错误，这会阻止任何成功回调函数工作，这意味着我无法使用 fileEntry。使用 fileEntry.createWriter() 或 fileEntry.createWriter() 来创建同名的新文件。
是否有其他方法可以从文件系统的逻辑索引中删除文件条目？
I'm using the HTML5 FileSystem API in a Chrome extension.
There's an unlikely (but possible) scenario where:
- A file is created using
fileWriter.write() - User navigates to their Chrome User Data folder > File System folder, and deletes the file that was created (using their operating system, not using the FileSystem API)
- All future calls of
getFile()for this file triggerFileError.NOT_FOUND_ERRin the error handler.
It seems that if a file is deleted outside of the FileSystem API, getFile() always errors for that file, which prevents any success callback function from working, meaning I can't use fileEntry.remove(), nor fileEntry.createWriter() to create a new file with the same name.
Is there an alternate way to remove the file entry from the FileSystem's logic index?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Windows 中的 Chrome 应用程序/扩展程序有一个奇怪的行为。事实上，如果您从应用程序的文件系统目录中手动删除该文件，您将无法创建同名的新文件。
目前唯一的解决方法是在第一次调用应用程序时创建某种主目录哈希。然后您应该将其名称写入（例如）本地存储并将文件写入此目录。您的哈希值必须足够唯一。就我而言，它是当前日期对象时间戳。因此，当用户删除并再次安装您的应用程序/扩展程序时，他们不会遇到此问题。
这仅指 Windows 系统。 Linux 操作系统（当然还有 ChromeOS）没有这个错误。
There's a strange behaviour in Windows for Chrome apps/extensions. The fact is that if you delete the file manually from the app's filesystem directory, you won't be able to create a new one with the same name.
The only workaround right now is to create some kind of home directory hash when you app is called for the first time. Then you should write its name to (say) Local Storage and write your files to this directory. Your hash must be unique enough. In my case it is current date object timestamp. So when users delete and install your app/extension again, they won't be faced with this problem.
This refers to Windows systems only. Linux OS (and ChromeOS of course) doesn't have this bug.