New files disappear from view after upload

[ioaoue]

I use elFinder 2.1.25 with this Java connector: https://github.com/bluejoe2008/elfinder-2.x-servlet
I try to upload some files one by one, for example, A, B and C.

1. File A uploads correctly.
2. File B uploads, shows in the veiw and disappears in less than a second.
3. File C uploads, shows in the veiw, disappears like B, and then I see file B instead of C.
4. If I continue, I will never see the last uploaded file until I reload the view. All other files shows correctly.

Such behavior was first introduced in commit d5ce45b:

-               if (cmd == 'open' || (cmd == 'info' && data.compare)) {
+               if (data.compare && (cmd == 'open' || cmd == 'info')) {

Maybe there were commits fixing this, but I did not found any. In the last release this line is fixed, but the bug is still present.

[nao-pon]

@ioaoue Is there a problem with Nightly build too? I verified with PHP connector 2.0 and 2.1, but there was no problem. Ask the developer of the Java connector because there is a possibility of a problem with the Java connector. If you find any problems with elFinder's client side program, please let me know as I will fix it.

[ioaoue]

I tested some versions from 2.1 branch including 2.1.12, 2.1.13, 2.1.20, 2.1.25 and the latest commit. Version 2.1.12 works correctly, and 2.1.13 do not. Then I did git bisect and found that d5ce45b is the first commit with this problem.

I looked at requests from elFinder client to connector and found that on https://studio-42.github.io/elFinder/ every file upload consists of 2 requests: "ls" and then "upload" commands. But on my server only the first file upload looks like that (and the first file uploads correctly). All subsequent uploads conist of 4 requests:

1. cmd=ls
   target=A_L3Rlc3Q_E
   intersect[]=1C
   

2. cmd=open
   reload=1
   target=A_L3Rlc3Q_E
   tree=1
   compare
   

3. cmd=ls
   target=A_L3Rlc3Q_E
   intersect[]=1C
   

4. -----------------------------148555191713858134561052379747
   Content-Disposition: form-data; name="cmd"
   
   upload
   -----------------------------148555191713858134561052379747
   Content-Disposition: form-data; name="target"
   
   A_L3Rlc3Q_E
   -----------------------------148555191713858134561052379747
   Content-Disposition: form-data; name="upload[]"; filename="1C"
   Content-Type: application/octet-stream
   
    
   
   -----------------------------148555191713858134561052379747
   Content-Disposition: form-data; name="mtime[]"
   
   1499745991
   -----------------------------148555191713858134561052379747
   Content-Disposition: form-data; name="upload_path[]"
   
   A_L3Rlc3Q_E
   -----------------------------148555191713858134561052379747
   Content-Disposition: form-data; name="dropWith"
   
   0
   -----------------------------148555191713858134561052379747--
   

And "open" request lasts much longer than subsequent "ls" and "upload". I think there could be some issue with asynchronous handling of responses.

1. Upload works fine and the file appears in the view.
2. ElFinder client handles response to the "open" command. This command was sent before the "upload" command, and the response does not contain new files.
3. ElFinder client updates the view and uploaded files disappear.

So I have 2 questions:

1. Why elFinder client sends "open" command to server? Maybe I should set some client options, or maybe connector sends incorrect response to the first "open" command (with "init" flag set)?
2. Why elFinder client sends "ls" and "upload" commands before it recieves response to the "open" command? Maybe I do something wrong?

[nao-pon]

Perhaps the result of your connector's ls command is incorrect.

1. elFinder requests the ls command in the preprocessing of the upload and checks the existing item. If the uploading file name is exists in results of ls and CWD does not have that file, elFinder will request the open command and try to keep the CWD up to date.
2. It seems to be a bug in elFinder. Since I attempted to fix it please check with Nightly build.

[ioaoue]

For now elFinder do not send the open command. Only ls, then upload. All works correctly.

[ioaoue]

If the uploading file name is exists in results of ls and CWD does not have that file, elFinder will request the open command and try to keep the CWD up to date.

For now I do not see this behavior. I tried:

1. Clear the folder
2. Create a file in that folder from server console
3. Upload a file into that folder with the same name

ElFinder client sent only 2 requests: ls and upload.

[ioaoue]

Did the same test on 2.1.25:

1. 1st ls request
2. 1st ls response
3. open request
4. 2nd ls request
5. 2nd ls response
6. upload request
7. upload response
8. open response

[nao-pon]

What data will your connector return to the ls command?

[ioaoue]

Captured full conversations for 2 cases:

• subsequent upload of files A and B into empty directory /test
  2.1.25_upload_ab.txt
  2.1.latest_upload_ab.txt
• upload of file A when it is present on the server, but client does not know about that
  2.1.25_upload_existing.txt
  2.1.latest_upload_existing.txt

Now I see at least one bug in the connector: it seems that it does not understand intersect parameter of the ls command.

[nao-pon]

The value returned by the ls command should be an object of item name with hash as key ( or array of item names). If intersect is given as a parameter, it is advisable to return only the item names that overlap in the array.

I edited Wiki - https://github.com/Studio-42/elFinder/wiki/Client-Server-API-2.1#ls . Please check out it.

[ioaoue]

I modified response from connector to match this format. Now ElFinder client works as expected. I think this issue could be closed.

Please update the wiki if there are some other errors in API description.

[nao-pon]

@ioaoue Thank you for your report. 👍