Linked files not retrieved with list_shared_links while files exists in dbx and appears as linked

[axew3]

Hi all!

Out of contest, i'm on the way to release a new wordpress plugin on wp repo, with a custom chooser (that i maybe will publish on github also, because the chooser is a standalone js piece of code/page, that i use iframed into this plugin). The custom chooser, upload files with progress bars and can be extended with easy, to be exactly the same of the native dbx chooser:  you'll use this without linking sites to get it work. I've just extend and little improve the github ready examples code. It appear a nice result. I'll publish as soon i can.

But before this, i come across to a problem that make me worry, since i can't understand at moment how it can happen.

the problem:

the code, perform curl calls to dbx to: retrieve list_shared_links, delete files, create folders, upload files, unlink files within users dbx wordpress pages etc. All nice and all working fine, but i note a problem that sometime suddenly happen without any obivious reason to me.

I test all things, so i go to delete some file, upload files, re-delete files, until (it seem to me but i'm still not completely sure if it happen exactly on deletion event) when i go to perform the deletion of some file, sometime, this happen:

after any curl call the code reload a sort of cache, just a txt file where json results are stored to retrieve file's links info. I note that on dropbox, at this time files and folders are linked to be viewed for anybody having the link, and this appear on dbx, but in true, these files or folders aren't retrieved performing a list_shared_links call.

I note that i have to unlink these files on dbx (because they appears as linked), so i re-share/link the file or folder: then when i reload the cache within the code that will perform a list_shared_links curl, files are correctly retrieved.

Substantially, it seem that sometime due to some occurred event, all files become unlinked (even if on dbx they still appear as linked), and the only way i can re-share these files/folders, would be to remove the link and create a new one, or the  list_shared_links call will retrieve nothing.

I'm little confused about this at moment, and may it come out due to some other reason that reside in the way the cache is built on my code.

So asking to myself if anybody else experience something like this!?

In the while i'm waiting for this behavior to occur another time, so will go deep to better understand where the problem is.

[Greg-DB · Accepted solution]

We'll be happy to look into this, but we'll likely need some more specific information to make sure we have a good understanding of the issue you're describing. Can you share the following:
- the specific steps to reproduce the issue
- the code used in those steps to reproduce the issue
- sample output showing the issue

If you'd prefer to share that privately, you can open an API ticket with it here:

https://www.dropbox.com/developers/contact

Thanks in advance!

[axew3]

Hi! Absolutely yes thank you! Honored 😉

I will do within today or tomorrow if the sky not fall down here ... i hope within today ...

But i need then to send you the entire plugin code.

The plugin use php for delete, unlink, list_shared_links, or create folder curl, while use the added dbx custom chooser, iframed onclick, to display the simple JS uploader.

This part, is the one that i'll like to start to develop, to be exactly (i will try with my simple JS code!) like the actual native dbx chooser is. At moment, it only upload any file on the folder where it is called, display progress bars, and also this part can be improved further more, where files are smaller then the min file size: when the file isn't chunched for upload, the progress bar fill to 100% in one time as soon the sharingCreateSharedLinkWithSettings finished. It is also easy to add a preloader for the file in this case (as it is on actual dbx chooser for uploaded files if i'm not wrong): the actual native dbx chooser just upload one by one files presenting related little preloader for the actual processed uploading file, and push it on list when upload finish, then follow with all other queued files ... which is to better way?

In effect i note that sometime, the upload fail with some file, but maybe this is because i've set the chunk size for testing purpose to 1mb and not to 8mb like dbx suggest. So sometime the "too many write requests" error occour. these errors are chatched and resolved in a simple way at moment, that can be really improved.

Will be easy to remove WP added parts and add any needed feature more via javascript (and will be githubbed😞 the custom chooser will add navigation to upload files into any folder like native chooser, the files chooser selection etc.

The actual code, like on the github example, automatically start to upload files when selected, on the folder where you are on, then reload cache and page automatically when upload queue finished.

I  have choose this way because initially i would like to release two versions, the free and not free ... you know ... but i will switch the intention to be only free version.

Funny that in the not free version, i was using the native dbx chooser, implemented on code in a strange way and working like a charm! But as said, and for this hte reason of custom chooser, the native dbx chooser require to add the domain for the site where it run on. And this is not possible for a free plugin presented at wordpress dot org repo.

I will try to send it to you with all explainations to make you up and running within the mess, because in true, the plugin has been coded more then 3 years ago if i'm not wrong, and it present many aspects that now i would like to rewrite in a complete different and more efficient way. I will do soon. I had overcomplicate many steps on php and using elementary js code concepts at this time, that now looks like newbie mistakes to me.

Now i have a better and much more clear idea about how all things need to be coded.

Let me finish with some little garbige and i'll send it immediately. Thank you Greg!

[Greg-DB]

Please try to reduce the code down the minimum amount needed to demonstrate/reproduce the issue. Thanks!

[axew3]

Unfortunately the code is within a plugin, it will require too much time to remove all things doing a standalone more short version of all (except the part about upload that is substantially an html/js file): easy, but too long! i will send the entire plugin, that need to be installed into a wordpress to work. If possible you'll maybe take a look into the two main php files i will indicate, that are containing the code that execute php curl calls. But i assume it do the work correctly, since normally it work fine and this behavior only sometime happen, but maybe i'm wrong.

I'm just experiencing right now the issue reported and another time i see this:

Using a full dropbox access, i had a single folder named wtest, linked on sharing:  i have upload 9 files on root (but the same result happened last time doing a deletion inside a linked test subfolder, so not root).

Then i have curl to delete these 9 files.

Result: next curl to list_shared_links, return nothing.

No reason looking into axew3 dbx account via browser, because the folder wtest apparently result as linked and anyone with the link should have access to it. A curl should return it, instead it is ignored. I've leave this folder wtest in this state if anyone would like (or have the power to) to take a look into this folder setting. It result as linked, but is not retrieved.

wtest folder about link setting result as follow:

Who can view this link? -> Anyone with the link can view

I'm quite sure that if i go to unlink the folder and to re-create the link, then the folder will return available like last times this is occurred. At moment i've leave the folder wtest in this state, creating a new folder testme and creating the link for it. It is correctly retrieved, while the wtest folder is not. I so assume that is a problem that happen on files deletion.

Sorry for the delay on posting the code to you, hard time here due to "no coding" reasons. I'll be over as soon i can.

[axew3]

Ok Greg, i've take a look in various little moments these days, and i've discover that there is a problem with my php recursion function.
The problem: the function work fine on first call, but after fall into a loop after second recursion, that before never was coming out because the code for other reasons was stopped and recursion never happen, so this was the reason of "folders not retrieved".
I ask you forgive me for this big mistake!
I just see now that the first returned cursor for recursion is different by the second logged, but after, the function retrieve ever the same cursor (that's at moment my doubt: i can't understand at moment why, after another curl the function return me another time the previous cursor value, so the recursive function loop because the next files array will be ever the same of before, and
$res_more->has_more
never become false!
This lead to the loop now. Should be easy to resolve, by the way i've still not understand why.
This stupid code i've do more then 2 years ago, is making me crazy. But i'm near to solution i guess! Sorry Greg, and thank you again!

[axew3]

Here again for a question:

it seem to me that the cursor return on results, even if the first call not retrieve 200 files?

I remember (maybe i'm wrong) that each curl retrieve 200 files.

So asking me why, if the first call not retrieve almost 200 files, it return by the way a cursor and has_more set as value 1.

???

I'm wrong? I get all working, after i apply a count() to the first call: i then will go to iterate only if files are more then 200, and not if the has_more is false (because it return 1 on first curl even if there aren't more then 200 files). Isn't it?

[axew3]

So just an hint to all cool people that eventually will fall into my same mess:
1) memo that the cursor ever return, and you need to count retrieved links to iterate or stop the iteration (this is true using http with php curl). I have forget this after long time (+ then 2 years), and i've lost my time behind this stupid thing another time now.
2) memo that maybe error,
PHP Fatal error: Maximum execution time of 30 seconds exceeded
can come out like in my case: set php ini to almost 60 sec, or you'll maybe thought like me, that the code was wrong looping in some part.
I will add a preloader for the curl execution time. I realize it is necessary.

My cache class was wrong, and the recursive function was failing in a specific situation.
Just to let know that now all is working like a charm.

... as we like to say: hope this will save an headache to someone else!