Google Drive Android API: Deleted folder still exists in query

Question

Running the code below, I create a folder with Google Drive Android API on a tablet. After a few seconds, delete that folder from a remote location on a PC. When I re-run the code, the API still thinks 'MyFolder' exists, even though it was deleted and not visible in the Google Drive app on the tablet. The folder persistance finally disappears after a while and the code works as expected. Is this expected behavior for Cloud drives?

Query query = new Query.Builder()
        .addFilter(Filters.and(Filters.eq(
                SearchableField.TITLE, "MyFolder"),
                Filters.eq(SearchableField.TRASHED, false)))
        .build();
Drive.DriveApi.query(getGoogleApiClient(), query)
        .setResultCallback(new ResultCallback<DriveApi.MetadataBufferResult>() {
    @Override
    public void onResult(DriveApi.MetadataBufferResult result) {
        if (!result.getStatus().isSuccess()) {
            showMessage("Cannot create folder in the root.");
        } else {
            boolean isFound = false;
            for(Metadata m : result.getMetadataBuffer()) {
                if(!isFound) {
                    if (m.getTitle().equals("MyFolder")) {
                        showMessage("Folder exists");
                        isFound = true;
                    }
                }
            }
            if(!isFound) {
                showMessage("Folder not found; creating it.");
                MetadataChangeSet changeSet = new MetadataChangeSet.Builder()
                        .setTitle("MyFolder")
                        .build();
                Drive.DriveApi.getRootFolder(getGoogleApiClient())
                        .createFolder(getGoogleApiClient(), changeSet)
                        .setResultCallback(new ResultCallback<DriveFolder.DriveFolderResult>() {
                    @Override
                    public void onResult(DriveFolder.DriveFolderResult result) {
                        if (!result.getStatus().isSuccess()) {
                            showMessage("Error while trying to create the folder");
                        } else {
                            mThwingAlbertFolderId = result.getDriveFolder().getDriveId();
                            showMessage("Created a folder: " + mThwingAlbertFolderId);
                        }
                    }
                });
            }
        }
    }
});

FYI, it's not directly related to your question, but you should change your "isFound" logic, instead of using an `if` inside your `for(Metadata m...)`, once you have found your folder, you should use a `break` command for better performance. — Leonardo, Sep 11 '15 at 19:35
Yep. I was going to add logic in for handling multiple instances of duplicate folder names, and never finished it because of this problem. Thanks. — vedavis, Sep 11 '15 at 20:47

score 7 · Accepted Answer · edited May 23 '17 at 11:53

What you are seeing, is a 'normal' behavior of the GDAA, that can be explained if you look closer at the 'Lifecycle of a Drive file' diagram (warning: I've never seen the source code, just assuming from what I observed).

See, the GDAA, unlike the REST Api, creates a layer that does its best to create caching and network traffic optimization. So, when you manipulate the file/folder from the 'outside' (like the web app), the GDAA layer has no knowledge of the fact until it initiates synchronization, controlled by it's own logic. I myself originally assumed that GooDrive has this under control by dispatching some kind of notification back to the GDAA, but it apparently is not the case. Also, some Googlers mentioned 'requestSync()' as a cure, but I never succeeded to make it work.

What you think you're doing, is polling the GooDrive. But effectively, you're polling the GDAA (local GooPlaySvcs) whose DriveId is still valid (not updated), unlike the real GooDrive object that is already gone.

This is one thing that is not clearly stated in the docs. GDAA is not the best Api for EVERY application. It's caching mechanism is great for transparently managing online/offline states, network traffic optimization. battery life, ... But in your situation, you may be better off by using the REST Api, since the response you get reflects the current GooDrive state.

I myself faced a similar situation and had to switch from the GDAA back to the REST (and replaced polling with a private GCM based notification system). Needless to say, by using the REST Api, your app gets more complex, usually requiring sync adapter / service to do the data synchronization, managing network states, ... all the stuff GDAA gives you for free).
In case you want to play with the 2 apis side-by side, there are two identical CRUD implementation you can use (GDAA, REST) on Github.

Good Luck

Thank you, @seanpj. Perfect answer! I had started with REST and saw the potential, but I thought it best to use Android API because that's what the Google Developer's page told me to do. I will be switching back. — vedavis, Sep 12 '15 at 13:56
... but watch out for the pains of managing delayed response, on/offline state, .. all the things that do not agree with the UI thread flow :-). — seanpj, Sep 12 '15 at 21:34

score 4 · Answer 2 · answered Jun 07 '16 at 11:50

Google drive api does not sync immediately, That is why the deleted folders are still showing, so you have to force google drive to sync using requestSync()

Drive.DriveApi.requestSync(mGoogleApiClient).await();

I fount an example snippet here: http://wiki.workassis.com/android-google-drive-api-deleted-folder-still-exists-in-query/

score 2 · Answer 3 · answered Sep 22 '15 at 01:34

As Sean mentioned, the Drive Android API caches metadata locally to reduce bandwidth and battery usage.

When you perform an action on the device, e.g. creating a folder, we attempt to apply that action on the server as soon as possible. Though there can be delays due to action dependencies and content transfers, you will generally see the results reflected on the server very quickly.

When an action is performed on the server, e.g. by deleting a folder via the web client, this action is reflected on the device the next time the Drive Android API syncs. In order to conserve battery and bandwidth, sync frequency depends on how the API is being used as this is a priority for users.

If you need to guarantee that a sync has occurred, you can explicitly request a sync using DriveApi.requestSync() and wait on the result. This is currently rate limited to 1 per minute, which is frequently hit during testing, but should have a much smaller impact on real world usage.

Please let us know on our issue tracker if this sync behavior is causing issues for your use case so we can investigate solutions.

score 1 · Answer 4 · edited Oct 25 '16 at 07:28

Google drive uses its own lifecycle for Drive api and manage all things in cache that's why if you delete some file or folder and try to access using google drive apis it is still available because it is stored in cache so you need to explicitly call requestSync() method for that then after that cache will be updated and gives you that folder or file not found. below is code for that:

Drive.DriveApi.requestSync(mGoogleApiClient).setResultCallback(new ResultCallback<Status>() {
        @Override
        public void onResult(@NonNull Status status) {
            Log.e("sync_status", status.toString());
            if (status.getStatus().isSuccess()) {
                setRootFolderDriveId();
            }
        }
    });

and don't call Drive.DriveApi.requestSync(mGoogleApiClient).await() because your main thread will block so it will crash. use above one and after get successful callback you can do your operation on google drive because it's updated.

score 1 · Answer 5 · answered Oct 04 '17 at 12:54

You can do it in main thread:

 Drive.DriveApi.requestSync(mGoogleApiClient).setResultCallback(new ResultCallback<com.google.android.gms.common.api.Status>() {
    @Override
    public void onResult(com.google.android.gms.common.api.Status status) {
        if (!status.getStatus().isSuccess()) {
            Log.e("SYNCING", "ERROR" + status.getStatusMessage());
        } else {
            Log.e("SYNCING", "SUCCESS");
            // execute your code to interact with Google Drive

        }
    }
});

score 0 · Answer 6 · answered Dec 28 '16 at 08:36

I was having the same issue and using "Drive.DriveApi.requestSync" did the trick. Also I suggest taking a look at https://github.com/francescocervone/RxDrive because you can concatenate the sync to other drive operations using rxandroid. For example, this becomes a delete-and-sync operation:

Observable<Boolean> deleteFile = rxDrive.delete(file);
Observable<Void> syncDrive = rxDrive.sync();
Observable.concat(deleteFile, syncDrive);

score 0 · Answer 7 · answered Jun 24 '20 at 19:11

0

The reason why you get listed deleted files from your query is that Google Drive has a "Trash" folder that is "searchable". You need to empty your trash first.

answered Jun 24 '20 at 19:11

gioolio

39
2

Google Drive Android API: Deleted folder still exists in query

7 Answers7

Linked