【问题标题】:removeItemAtPath on a file already open已打开文件上的 removeItemAtPath
【发布时间】:2010-10-22 15:13:02
【问题描述】:

我在 iPhone 上打开了一个文件,我正在通过网络发送数据(使用“_open”打开)。但是我可以从 iphone 的界面中删除文件。这是使用 NSFileManager 的 removeItemAtPath 完成的。

奇怪的是即使文件当前已打开,removeItemAtPath 也会成功。

文件通过网络完美传输,并且 removeItemAtPath 在传输完成之前成功。那么 removeItemAtPath 是否会进行延迟删除?即,如果文件正在使用,它是否会排队以备后用?如果是这样,那么没有问题。

如果不是...有谁知道我如何让 NSFileManager 实际报告它没有执行删除的事实?

谢谢!

【问题讨论】:

    标签: c++ iphone objective-c nsfilemanager


    【解决方案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 停止删除项目。如果该项是目录,则也不会删除该项的子项。

    阅读让我相信这是一个异步操作,并且不应使用此方法的返回值来确定文件是否已成功删除。我的猜测是它将对象排队等待删除,并在文件不再使用时被删除。

    【讨论】:

    • 猜一下就好了。我需要知道。我没有实现 shouldRemoveItemAtPath 顺便说一句。同样,没有什么能阻止它保持完全同步。我不明白这意味着任何程度的异步性......
    • 我认为这不仅仅是猜测。这是苹果官方文档。如果成功删除的返回值为 YES 或删除不成功的返回值为 NO ,那么它将说明这一点。然而,它告诉我们的只是该方法的最佳猜测是删除将继续。
    • 好吧,我检查过了。该文件不会立即被删除。传输完成后,如果我再次尝试传输文件,它会在 iPhone 上返回“不存在”。已排序。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2023-01-15
    • 2012-05-03
    • 1970-01-01
    • 2022-06-15
    • 2010-10-28
    • 1970-01-01
    • 2014-05-02
    相关资源
    最近更新 更多