*bug* Seafile pro: after update from 5.1.3 to 6.1.9.: Some folders are not shown in the web interface


#1

Hi!

after update from 5.1.3 to 6.1.9. seafile pro: Some folders are not shown in the web interface. In the windows client all folders are shown.

What I tried: stop an restart seafile and seahub. It did not change the problem.

Any ideas?

Best regards,
Pfeffer.


#2

I tried something more:
As I said, in the windows client all folders and their content is shown and accessible using the seafile-browser. So, I tried creating a download link:
a) A download link works, when it was created for a folder that is shown in the web interface
b) A download link does not work, when it was created for a folder that is not shown in the web interface

So, my guess was that there might be some data corruption and I run seaf-fsck. It did not find any error.

Any more idea what I can do (or try) in order to be able to access all folders also from the web interface?

Best regards,
Pfeffer


#3

Can you try another browser?


#4

I tried:

  • FireFox 57.0
  • Chrome 62.0.3202.94
  • Edge 41.16299.15.0 / 16.16299
    with no difference.

I have to correct one point: the download-link created in the seafile desktop client works now, even if dealing with a folder that is not shown in the library in the web interface.

Any more idea?

Best regards,
Pfeffer.


#5

I would think it is a bug then, but I cannot reproduce it.

Is there anything in your seahub_django_request.log?


#6

no - not any entry from today.

In seafile.log are new entries, but they seem to me to be irrelevant:

[11/24/2017 11:22:46 PM] filelock-mgr.c(924): Cleaning expired file locks.
[11/24/2017 11:22:49 PM] size-sched.c(103): Repo size compute queue size is 0
[11/24/2017 11:27:49 PM] size-sched.c(103): Repo size compute queue size is 0
[11/24/2017 11:32:49 PM] size-sched.c(103): Repo size compute queue size is 0

ccnet.log:

[11/24/17 23:14:33] ../common/peer.c(950): Local peer down
[11/24/17 23:24:32] ../common/session.c(409): Accepted a local client
[11/24/17 23:24:33] ../common/peer.c(950): Local peer down
[11/24/17 23:34:33] ../common/session.c(409): Accepted a local client
[11/24/17 23:34:33] ../common/peer.c(950): Local peer down

seafevents.log:

[2017-11-24 22:53:31,677] [DEBUG] Running command: "/usr/bin/python2.7" "/opt/seafile/seafile-pro-server-6.1.9/seahub/manage.py" "send_queued_mail", cwd = /opt/seafile/seafile-pro-server-6.1.9/seahub
[2017-11-24 22:54:31,840] [INFO] starts to index files
[2017-11-24 22:54:31,841] [DEBUG] Running command: "/usr/bin/python2.7" "-m" "seafes.update_repos" "--logfile" "/opt/seafile/logs/index.log" "update", cwd = /opt/seafile/seafile-pro-server-6.1.9/pro/python/seafes
[2017-11-24 23:04:31,949] [INFO] starts to index files
[2017-11-24 23:04:31,950] [DEBUG] Running command: "/usr/bin/python2.7" "-m" "seafes.update_repos" "--logfile" "/opt/seafile/logs/index.log" "update", cwd = /opt/seafile/seafile-pro-server-6.1.9/pro/python/seafes
[2017-11-24 23:14:32,053] [INFO] starts to index files
[2017-11-24 23:14:32,054] [DEBUG] Running command: "/usr/bin/python2.7" "-m" "seafes.update_repos" "--logfile" "/opt/seafile/logs/index.log" "update", cwd = /opt/seafile/seafile-pro-server-6.1.9/pro/python/seafes
[2017-11-24 23:23:31,776] [INFO] starts to send email
[2017-11-24 23:23:31,777] [DEBUG] Running command: "/usr/bin/python2.7" "/opt/seafile/seafile-pro-server-6.1.9/seahub/manage.py" "send_notices", cwd = /opt/seafile/seafile-pro-server-6.1.9/seahub
[2017-11-24 23:23:31,786] [DEBUG] Running command: "/usr/bin/python2.7" "/opt/seafile/seafile-pro-server-6.1.9/seahub/manage.py" "send_queued_mail", cwd = /opt/seafile/seafile-pro-server-6.1.9/seahub
[2017-11-24 23:24:32,127] [INFO] starts to index files
[2017-11-24 23:24:32,128] [DEBUG] Running command: "/usr/bin/python2.7" "-m" "seafes.update_repos" "--logfile" "/opt/seafile/logs/index.log" "update", cwd = /opt/seafile/seafile-pro-server-6.1.9/pro/python/seafes
[2017-11-24 23:34:32,231] [INFO] starts to index files
[2017-11-24 23:34:32,232] [DEBUG] Running command: "/usr/bin/python2.7" "-m" "seafes.update_repos" "--logfile" "/opt/seafile/logs/index.log" "update", cwd = /opt/seafile/seafile-pro-server-6.1.9/pro/python/seafes

What else can I do in order to help you find the bug?

EDIT: The library contains 578 items, mainly folders. The webbrowser EDGE shows 400 of them.

Best regards,
Pfeffer.


#7

I’m also only community member :wink:

But you could look in the developer console of your browser to see if there is an error and to see which data is being requested.


#8

ahh, thank you for helping in diagnosis!

in EDGE: The javascript console does not show any error or warning.

What might be helpful:
If I scroll down very, very slowly EDGE loads once more folders. FireFox doesnot.

FireFox gives a warning in the javascript console:
Diese Website verwendet anscheinend einen scroll-verknüpften Positionierungseffekt. Dies könnte mit asynchronem Verschieben (Panning) schlecht zusammenspielen; siehe https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects für weitere Details und nehmen Sie an der Diskussion über damit verbundene Werkzeuge und Funktionen teil!

Which translates to something like:
This website seems to use a posititioning effect based von scrolling. This could cause problems with asynchronically moving (Panning); see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for more details and discuss about linked tools and functions!

Chrome’s console might also be helptful:

main.ce0533b25c52.js:212 [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952
add @ main.ce0533b25c52.js:212
(anonymous) @ main.ce0533b25c52.js:212
each @ main.ce0533b25c52.js:212
each @ main.ce0533b25c52.js:212
on @ main.ce0533b25c52.js:212
delegateEvents @ main.ce0533b25c52.js:212
t.View @ main.ce0533b25c52.js:212
i @ main.ce0533b25c52.js:212
initialize @ main.ce0533b25c52.js:212
t.Router @ main.ce0533b25c52.js:212
i @ main.ce0533b25c52.js:212
(anonymous) @ main.ce0533b25c52.js:212
execCb @ require.640929dac3c2.js:1658
check @ require.640929dac3c2.js:874
enable @ require.640929dac3c2.js:1151
enable @ require.640929dac3c2.js:1519
(anonymous) @ require.640929dac3c2.js:1136
(anonymous) @ require.640929dac3c2.js:132
each @ require.640929dac3c2.js:57
enable @ require.640929dac3c2.js:1098
init @ require.640929dac3c2.js:782
(anonymous) @ require.640929dac3c2.js:1424
require.640929dac3c2.js:1413 [Violation] 'setTimeout' handler took 253ms
main.ce0533b25c52.js:212 [Violation] 'readystatechange' handler took 593ms

#9

I think this is very useful.

I think this is something you should look into @daniel.pan . It has been reported multiple times and I think with this information in mind a fix should be possible.


#10

@daniel.pan push


#11

We will take a look at the problem. Anyway, in version 6.3, the scrollbar will be redesigned which may eliminate the problem.


#12

@daniel.pan: Thanx. In case you need more information to find the cause, let me know.