如何测试应用程序是否正确处理缓慢/不稳定的文件系统？
我想确保我的应用程序在处理慢速文件系统（例如网络、CD/DVD 或旋转 HDD）上的文件时不会出现任何 UI 冻结。
我直接使用 Cocoa 文件系统操作。我担心仅仅为了测试而模拟或抽象所有这些会花费太多的精力，而且我的程序可能会以不明显的方式接触文件系统。
我尝试过使用网络驱动器进行测试，但操作系统缓存使测试不可重复并且...太快:)
是否有故意缓慢的 MacFuse 文件系统之类的东西？还有其他方法可以让我找到由意外延迟引起的所有 UI 问题和竞争条件吗？
I want to ensure that my application doesn't have any UI freezes when working on files on slow filesystem (e.g. networked, CD/DVD or spun-down HDD).
I'm using Cocoa filesystem operations directly. I'm afraid it would be too much effort to mock or abstract all of it just for testing, and besides there could be non-obvious ways in which my program touches filesystem.
I've tried using network drives for testing, but OS caching makes tests non-repeatable and... too fast :)
Is there something like deliberately slow MacFuse filesystem? Some other method that would let me find all UI hiccups and race conditions caused by unexpected delays?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
最简单的答案是 MacFUSE，如其他地方所述；这很容易模拟。您还可以尝试通过 NFS 挂载共享，然后使用内置的 ipfw 对其进行位限制，例如：
ipfw pipeline 1 config 1KByte/s
ipfw add 1 pipeline 1 src-port 2049
或者如果您使用 WebDAV
ipfw add 1 pipeline 1 src-port 80
这将在您定义的任何管道级别上滴灌请求。之后您应该可以使用以下命令再次删除它：
ipfw delete 1
The easiest answer is MacFUSE as noted elsewhere; that's pretty easy to simulate. You could also try mounting a share over NFS and then use bit throttling it using the built-in
ipfw, like:ipfw pipe 1 config 1KByte/s
ipfw add 1 pipe 1 src-port 2049
or if you're using WebDAV
ipfw add 1 pipe 1 src-port 80
This will then drip-feed the requests through at whatever pipe level you've defined. You should be able to get rid of it again afterwards with:
ipfw delete 1
也许买一个慢速拇指驱动器？我在百思买发现了一些冰冷的东西。通过多个 USB 集线器或者键盘将它们插入，这样它们的连接就非常方便。
-W
Maybe buy a slow thumb drive? I've found some at Best Buy that were glacial. Plug them in through several USB hubs and maybe a keyboard, as well, so they'll be on a very pokey connection.
-W
使用 Cocoa 框架编写 MacFUSE 文件系统非常简单。事实上，我认为甚至包含一个示例系统，它只是镜像本地文件系统。为什么不快速调整该代码，以便在每次操作期间调用 sleep() 一会儿？
Writing a MacFUSE filesystem with their Cocoa framework is dead easy. In fact I think there's even an example system included that just mirrors the local filesystem. Why not quickly adapt that code so that it calls sleep() for a moment during every operation?
根据您担心出现问题的位置，我的第一个想法是在应用程序和文件 I/O 之间添加一个额外的函数调用层，并在该层中构建一些 sleep() 调用。也就是说，无论您使用什么语言，都将“read”调用替换为“readDelegate”，并让 readDelegate 休眠一段指定的时间，然后进行真正的读取并返回值。当您准备好投入生产时，您甚至不需要拉出额外的层，只需删除睡眠即可。
Depending on where you're worried about having problems, my first thought would be to just include an extra layer of function calls between the app and the file i/o, and in that layer build in some sleep() calls. That is, whatever language you're using, replace the "read" call with "readDelegate", and let readDelegate sleep for some specified amount of time, then do the real read and return the value. When you're ready to go to production, you wouldn't even have to pull out the extra layer, just remove the sleep.
软盘驱动器怎么样？必须有外部的，您可以通过 USB 等简单地连接...
How about a floppy drive? There must be external ones that you can simply connect via usb or so...