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.
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
Can you try another browser?
I tried:
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.
I would think it is a bug then, but I cannot reproduce it.
Is there anything in your seahub_django_request.log?
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.
I’m also only community member 
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.
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 593msI 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.
We will take a look at the problem. Anyway, in version 6.3, the scrollbar will be redesigned which may eliminate the problem.