The list_folder/continue api is needed for an API user to track changes to files under a given folder. If the folder is moved, the list_folder/continue API will return a path not found error. If the id of the folder is known, the changes watching can be started again on the same folder via a call to get_metadata to get the file's path, then list_folder/continue with the file path. However, any changes that occur between when the folder is moved, and when the new list_folder/continue call is made will be lost. This is really bad for anybody that relies on the list_folder/continue api for maintaining the consistency of their local state. I ran the following experiment: 1. Create a folder and start watching changes via list_folder/continue 2. Add a file to the folder. list_folder/continue shows the new file change. 3. Move the folder to another location. 4. list_folder/continue returns path not found. 5. Add a file to the folder in the new location. 6. Move the folder back to its original location. 7. Call list_folder/continue again. The new file, and the file added to the folder when it was in the different location are listed. From this experiment I can conclude the list_folder/continue api is independent of folder location. It is only time based. On my assumption that list_folder/continue is time based, can you allow us to supply a 'from' parameter that will list folder changes from a given point in time? Alternatively, can you make the list_folder/continue api support access by file ids so that we don't lose track of changes when a folder is moved, as was one of the purported major features of api v2.
... View more
The get_folder_metadata documentation states that the path_lower field in the response body. I needto give my users a descriptive error message when it's not available. So I can write an instructional message, can you answer the following? Is path_lower only absent when the folder is not mounted? Is a folder mounted when the user accepts the shared folder invitation? Also, why is there no path_display present on the metadata response?
... View more