有一种简单的机制来确定当一个下载管理器删除（）已完成，因为它似乎是部分异步的。该函数返回几乎在瞬间与它的删除，在下载表中的条目的数量，但实际的文件系统看家似乎被推到一些后台线程。

问题是我已经写了code，看起来并删除文件X（并希望该文件系统对象）任何现有的下载管理器进入，拉动新副本前的一点点。不幸的是，新副本做它的目录文件系统看家已经拉开之前，为previous化身。所以实际上看家最终删除新版本在某些时候和离开的下载管理器表中的孤儿项。

可以做一些方法来阻止，直到文件系统删除的付诸行动。

调试code：

  DownloadManager.Query查询=新DownloadManager.Query（）setFilterByStatus（DownloadManager.STATUS_SUCCESSFUL）。    下载= getAllDownloadIds（manager.query（查询））;    PATH = activity.getExternalFilesDir（Environment.DIRECTORY_DOWNLOADS）;    //如果文件名传递删除该文件中的任何现有项/版    如果（文件名= NULL＆放大器;！＆安培;！fileName.isEmpty（））{        如果（downloads.containsKey（文件名））{            IDS = downloads.get（文件名）;            为（长ID：IDS）{                URI路径= manager.getUriForDownloadedFile（ID）;                文件checkFile =新的文件（path.toString（））;                Log.e（TAG，删除现有的文件：+ path.toString（）+：+身份证）;                INT entriesRemoved = manager.remove（ID）;                Log.e（TAG，现有文件中删除：+ entriesRemoved）;            }        }    }...Log.v（TAG，试图在外部存储中创建的下载目录中的文件::+ path.toString（）+/+文件名）;文件=新的文件（路径，文件名）;Log.v（TAG，它的文件已经存在::+ file.exists（））; 

输出示例：

  ... V /导出：拆除现有的文件：文件：///storage/sdcard/Download/appData.csv：101... V /导出：现有文件中删除：1... V /导出：试图在外部存储上创建的下载目录中的文件:: /存储/ SD卡/下载/ appData.csv... V /导出：是否该文件已经存在::真 

解决方案

我有同样的问题 - 在一个快速网络替换小文件时，替换文件有时会一秒钟的时间内到达调用后 DownloadManager.remove（...）在这种情况下，新到达的文件将被删除。

我使用的解决方案是，在此之前我叫 DownloadManager.remove（...），我设置了一个的 FileObserver 监视文件。然后，我打电话删除（...），但随后等待DELETE事件开始更换下载之前开火。

这是结束的多个类之间的分配code的显著量。还有其他复杂的因素 - 比如我把超时机制在公正的情况下下载管理器永远不会删除该文件。 （我不能为什么会无法想象的，但它不是我的组件）。

那么，现在回答这个问题：有没有一种简单的机制.....：有可用的机制给你，但遗憾的是特别不容易的人

Is there an easy mechanism to determine when a DownloadManager remove() has completed, as it appears to be partially asynchronous. The function returns almost instantaneously with a count of the entries in the Download table it's deleted, but the actual filesystem housekeeping appears to be pushed into some background thread.

Issue is I've written a little bit of code that looks for and deletes any existing DownloadManager entry for file X (and hopefully the filesystem object), before pulling a new copy. Unfortunately the new copy is making it to the directory before the filesystem housekeeping has kicked in, for the previous incarnation. So the housekeeping actually ends up deleting the new version at some point and leaving an orphan entry in the DownloadManager table.

Could do with some way to block till the filesystem delete is actioned.

Debug code:

    DownloadManager.Query query = new DownloadManager.Query().setFilterByStatus(DownloadManager.STATUS_SUCCESSFUL);
    downloads = getAllDownloadIds(manager.query(query));

    path = activity.getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS);

    //If a file name was passed remove any existing entry / version of the file
    if ( fileName != null && ! fileName.isEmpty() ){
        if ( downloads.containsKey(fileName)){
            ids = downloads.get(fileName);
            for (Long id : ids) {
                Uri path = manager.getUriForDownloadedFile(id);
                File checkFile = new File(path.toString());
                Log.e(TAG, "Removing existing file: " + path.toString() + ":" + id);
                int entriesRemoved = manager.remove(id);
                Log.e(TAG, "Existing files removed: " + entriesRemoved);                  
            }
        }
    }


...
Log.v(TAG, "Attempting to create a file in the 'Download' directory on the external storage::" + path.toString() +"/"+ fileName);
file = new File(path, fileName);
Log.v(TAG, "Does the file already exist::" + file.exists());

Example output:

… V/Export﹕ Removing existing file: file:///storage/sdcard/Download/appData.csv:101
… V/Export﹕ Existing files removed: 1
… V/Export﹕ Attempting to create a file in the 'Download' directory on the external storage::/storage/sdcard/Download/appData.csv
… V/Export﹕ Does the file already exist::true

I had this same problem - when replacing small files in a fast network, the replacement files would sometimes arrive within a fraction of a second after calling DownloadManager.remove(...) In this case, the newly arrived files would be deleted.

The solution I'm using is, before I call DownloadManager.remove(...), I setup up a FileObserver to monitor the file. I then call remove(...), but then wait for the DELETE event to fire before initiating the replacement download.

This ended being a significant amount of code distributed among multiple classes. There are other complicating factors - for example I put a timeout mechanism in just in case the DownloadManager never deletes the file. (I can't imagine why it wouldn't, but it's not my component).

So in answer to the question "Is there an easy mechanism.....": There are mechanisms available to you, but unfortunately not particularly easy ones.