2 file_ids are pointing to same file

[Info V.1]

"id:sQ8JqHEl8OkAAAAAAAIbNQ" and "id:sQ8JqHEl8OkAAAAAAAIbSg" both point to the same file. I received file_delete event with "id:sQ8JqHEl8OkAAAAAAAIbSg" and received file_download event for same file with "id:sQ8JqHEl8OkAAAAAAAIbNQ". Why do we see this issue?

[Greg-DB]

Thanks for the post. I'll check on this for you and follow up here when I have some information for you.

[Greg-DB]

Thanks for your patience while I checked on this for you. While file IDs uniquely identify files, i.e., every file ID identifies a file, and no two files share a file ID, it is possible for two different file IDs to essentially "point" to a single file.

It looks like that's what's happening here. Because of the sharing, unsharing, and restoring operations you performed, you received multiple file IDs over time, but there is only one latest/active instance of the file now. So, querying for either the past file ID or the current one points to the latest active instance of the file.

[Info V.1]

Thanks for you response Greg,

We (Vera Security) have integration with Dropbox and use the IDs to uniquely identify the file in our system. We listens to the DB events, use the ID to find the file in our system and then perform the corresponding action.

Now if the ID is changed then we cannot find the corresponding file in our system and it breaks the integration.

Can you help us better understand what exactly causes the new ID creation? I have tried sharing, unsharing, delete / restore but I am unable to reproduce it again. 

[Info V.1]

We found a consistent way to reproduce the issue.

1. Create 2 folders on Dropbox and share folders with any users
2. As a user1 upload file into folder1
3. As a user1 move file to folder2 
4. As a user1 (file owner) remove file. Notice that only file_delete event comes with different file_id.

I have file_operations logs to show this issue. Is there a way to get file_delete with same id as other events? Is this a recent change from your side?

[Greg-DB]

Thanks for following up. I'm glad to hear you already tracked down how to reproduce this. 

I don't believe this is a new behavior; it's just appears to be not as common. Unfortunately, there isn't a way to change how the file ID system works.

You can essentially "resolve" these file IDs though, by calling the API with them. As you saw in the screenshot in your first message, when you call with "id:sQ8JqHEl8OkAAAAAAAIbSg", the response returned the current "id:sQ8JqHEl8OkAAAAAAAIbNQ". You can use that to determine the relation between the two IDs if you need.

[Info V.1]

Workaround provided will not work because once the file is deleted we dont get the fileId in get_metadata call. Example of "get-metadata" call after delete is:

{
    ".tag": "deleted",
    "name": "move_and_delete.png.html",
    "path_lower": "/dropbox_regression/delete/move_and_delete.png.html",
    "path_display": "/Dropbox_Regression/delete/move_and_delete.png.html"
}

 And, screenshot provided in first comment was after the file is restored.

[Greg-DB]

I see, thanks for clarifying that screenshot. I'm afraid I don't have a solution to offer, but I'm sending this along as feedback to the team.