DeletedMetadata objects don't "expire" exactly, but whether or not old ones would still be returned (e.g., when calling files_list_folder/files_list_folder_continue again) after a significant period of time depends on a few specifics, based on the particular account's features, file activity, and some specifics of how the Dropbox backend works.
The guarantee that the API provides is that as long as you implement files_list_folder and files_list_folder_continue as documented, you'll end up with the correct state matching what's on the server:
DeletedMetadata objects don't "expire" exactly, but whether or not old ones would still be returned (e.g., when calling files_list_folder/files_list_folder_continue again) after a significant period of time depends on a few specifics, based on the particular account's features, file activity, and some specifics of how the Dropbox backend works.
The guarantee that the API provides is that as long as you implement files_list_folder and files_list_folder_continue as documented, you'll end up with the correct state matching what's on the server:
But I guess that because state matching depends on DeletedMetadata, it is only guaranteed so long as the sync is performed regularly, right?
Otherwise, if old deleted files are not registered when calling files_list_folder (as DeletedMetadata), one cannot maintain the same state as on the server.
The amount of time between your calls to /list_folder[/continue] doesn't matter. The server will always return the entries necessary to make sure you get an accurate state based on the cursor you provide, as long as you process the entries as documented.
I'm unable to retireve Deleted Metadata for deleted files/folders that are permanently deleted.
Doesn't this then mean that local state is only guaranteed to match that of the server, if the deleted file is still recoverable?
If so, then this is sort of what I was eluding to in my original post, in that Dropbox will permanently delete files after some time period, depending on the account type.
