设备浏览问题
我正在编写文件浏览软件，我希望它能够在所有便携式设备上正常工作，例如相机、智能手机等。我的程序显示缩略图，所以我需要读取每个文件的内容。
现在我面临一些问题：
使用我的两台相机，我只能从设备打开一个 ISteam。对于每个附加流，我都会收到 ERROR_BUSY 错误。这很不方便，因为我在多个后台线程中获取缩略图。
我可以从智能手机打开多个流，但我无法寻找这些流！作为解决方法，我必须将整个流复制到临时文件系统位置并在那里进行处理。
我想知道这取决于什么。设备文件系统？驱动程序实现？还是其他什么？
I’m writing file browsing software and I want it to work correctly with all portable devices, such as cameras, smart phones and so on. My program shows thumbnails, so I need to read the content of each file.
Now I’m facing some problems:
With both my photo cameras I can open only one ISteam from device. For every additional stream I get ERROR_BUSY error. This is inconvenient as I get thumbnails in several background threads.
I can open multiple streams from my smart phone, but I cannot seek that streams! As workaround I have to copy the entire stream to temp file system location and process it there.
I wonder what it depends on. Device file system? Driver implementation? Or anything else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这些似乎是对内存非常有限的外设的文件访问的非常合理的限制（有限的快速易失性内存和代码 EEPROM 比闪存卡的大小更值得关注）。
这不是文件系统（对于此类设备来说几乎普遍为 FAT 或 FAT32），甚至不是 Windows 驱动程序中的限制（尽管可能强制执行这些限制以避免设备混淆），而是设备嵌入式文件描述符数量有限。文件访问代码。
因此，您可能必须针对这些和其他不受支持的驱动程序功能找到解决方法。
与此相关的是，多线程通常不是执行后台 I/O 操作的正确方法。如果您的设备支持 OVERLAPPED 操作，那么您可以将其与事件和 MsgWaitForMultipleObjects 一起使用（它取代经典 GetMessage/TranslateMessage/DispatchMessage 主事件循环中的 PeekMessage 或 GetMessage）。通过将所有内容保留在一个线程上，您可以避免同步问题、大多数竞争条件，并防止以下问题：
她设备上的文件之一，但是
哦不，正在使用唯一的 IStream
在线程上阅读缩略图。也
不好，必须等待该线程
完成当前文件。
Those seem like very reasonable restrictions on file access to a peripheral with very limited memory (limited fast volatile memory and code EEPROM are more of a concern than size of the flash card).
It's not the file system (which is almost universally FAT or FAT32 for these kinds of devices) or even limitations in the Windows driver (although the limits are probably enforced there to avoid confusing the device) but limited number of file descriptors in the device's embedded file access code.
As a result, you'll probably have to have workarounds for these and other unsupported driver features.
On a related note, multiple threads usually aren't the right way to do background I/O operations. If your devices support OVERLAPPED operation then you can use that along with events and MsgWaitForMultipleObjects (which replaces PeekMessage or GetMessage in the classic GetMessage/TranslateMessage/DispatchMessage main event loop). By keeping everything on one thread you avoid synchronization issues, most race conditions, and prevent the following problem:
one of the files on her device, but
oh no, the only IStream is being used
on a thread reading thumbnails. Too
bad, have to wait for that thread to
finish its current file.