在已打开的文件上删除ItemAtPath
我在 iPhone 上打开了一个文件，我正在通过网络发送该文件的数据（使用“_open”打开）。不过我可以从 iPhone 界面删除文件。这是使用 NSFileManager 的removeItemAtPath 完成的。
奇怪的是，即使文件当前已打开，removeItemAtPath 也会成功。
文件在网络上完美传输，并且在传输完成之前removeItemAtPath 已成功。那么removeItemAtPath是否会执行延迟删除？即，如果文件正在使用中，它是否会将其排队以供稍后使用？如果是这样那就没问题了。
如果没有......有谁知道我如何让 NSFileManager 实际报告它没有执行删除的事实？
谢谢！
I have a file open on the iPhone that I am sending the data of across the network (Opened using "_open"). However I have the ability to delete files from the iphone's interface. This is done using NSFileManager's removeItemAtPath.
The odd thing is that removeItemAtPath is succeeding even though the file is currently open.
The file transfers perfectly across the network and removeItemAtPath succeeds before the transfer is complete. So does removeItemAtPath do a lazy delete? ie does it queue it for later if the file is in use? If so then no problems.
If not ... does anyone know how I can get NSFileManager to actually report the fact that it didn't do the delete?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
的文档
根据http://developer.apple.com/library/ios/documentation/cocoa/reference/foundation/Classes/NSFileManager_Class/Reference/Reference.html#//apple_ref/occ/ instm/NSObject/fileManager:shouldRemoveItemAtPath：
如果操作应该继续，则
shouldRemoveItemAtPath返回YES，不一定已经成功删除了该项目。同样有趣的是，文档指出：讨论从此方法返回 NO 会导致 NSFileManager 停止删除该项目。如果该项目是目录，则该项目的子项目也不会被删除。
阅读这让我相信这是一个异步操作，并且该方法的返回值不应该用于确定文件是否已成功删除。我的猜测是，它将对象排队等待删除，并且当文件不再使用时将被删除。
According to the documentation at
http://developer.apple.com/library/ios/documentation/cocoa/reference/foundation/Classes/NSFileManager_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/fileManager:shouldRemoveItemAtPath:
shouldRemoveItemAtPathreturns YES if the operation should proceed, not necessarily that it already successfully deleted the item. It's also interesting that the documentation states:Discussion Returning NO from this method causes NSFileManager to stop deleting the item. If the item is a directory, no children of that item are deleted either.
Reading that leads me to believe this is an asynchronous operation and that the return value of this method should not be used to determine if the file was successfully deleted. My guess is that it queues the object for deletion and will be deleted when the file is no longer in use.