Closed timreeves closed 8 years ago
I was under the impression that OC-ETag has been supported in the client for a very long time. (since about 1.8.x) So there should normaly be no problem. If there is a problem, that's a bug. The client log would be helpfull to understand why the etag were different.
Now I found out how to get the log (F12) and of course, the problems which I was having, and have cleared by manual intervention, are long gone. If I have any more problems, I'll check it straight away. I did notice this recurring message group:
10-23 21:37:03:872 0x4ad7bb0 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (Die angegebene Prozedur wurde nicht gefunden.) 10-23 21:37:03:875 0x4ad7bb0 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001
10-23 21:37:03:876 0x4ad7bb0 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available 10-23 21:37:03:931 0x4ad7bb0 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (Die angegebene Prozedur wurde nicht gefunden.) 10-23 21:37:03:934 0x4ad7bb0 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001
10-23 21:37:03:934 0x4ad7bb0 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available
HA well it seems maybe that is the problem, as noted above: A sync just failed again, and the only log entries for that time (the last entries in the log, I dived right in) are these:
10-23 21:58:28:691 0x4ad7bb0 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (Die angegebene Prozedur wurde nicht gefunden.) 10-23 21:58:28:692 0x4ad7bb0 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001 10-23 21:58:28:692 0x4ad7bb0 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available
MEA CULPA - Sorry!
I had this in my nginx-config:
location ~ robots.txt { allow all; log_not_found off; access_log off; } location ~ nginx(.*).conf { deny all; return 404; }
which of course is plain crazy, it was returning a 404 to all files CONTAINING "nginx" + ".conf" - and since I was just working with a lot of such files (PHP-FPM + Nginx = FAST), it made it look like a general problem since occuring frequently. What it should be (i.e. specific to topmost dir):
location = /robots.txt { allow all; log_not_found off; access_log off; } location = /nginx-{whatever-you-call-it}.conf { deny all; return 404; }
Final notes/wishes:
My Nginx-Config for PHP-FPM (running on a Plesk VPS, but outside of Plesk, an own compiled PHP):
set $sockname ##YOUR-WS##;
if ($server_port = 80) { rewrite ^ https://$server_name$request_uri? permanent; }
charset utf-8;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
error_page 403 /core/templates/403.php; error_page 404 /core/templates/404.php;
fastcgi_buffers 64 4K;
location = /robots.txt { allow all; log_not_found off; access_log off; } location = /nginx-for-own-phpfpm-owncloud.conf { deny all; return 404; }
location ~ ^/(?:.|3rdparty|config|console|db_structure|indie|lib|occ|templates).* { deny all; return 404; }
location ~ ^((?U).+?.php)(/.*)?$ {
fastcgi_split_path_info ^((?U).+.php)(/?.+)$; set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
fastcgi_param PATH_INFO $path_info;
fastcgi_param PATH "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"; fastcgi_pass "unix:/usr/local/php-fpm-pool.d/$sockname.sock";
include /etc/nginx/fastcgi.conf;
}
location ~* .(js|css|htm|html|xhtml|xml|json)$ { try_files $uri =404; expires 1d; add_header Pragma public; add_header Cache-Control public; access_log off;
}
location ~* .(png|jpg|jpeg|gif|ico|bmp|img|ttf|otf|eot|svg|svgz|woff)$ { try_files $uri =404; expires 30d; add_header Pragma public; add_header Cache-Control public; access_log off;
}
location ~* .(bz2|exe|gz|pdf|rar|tgz|zip)$ { try_files $uri =404; expires 2w; add_header Pragma public; add_header Cache-Control public; access_log off;
}
location ~* .(ac3|avi|flv|iso|mp3|mp4|mpeg|mpg|ogg|qt|rm|swf|wav)$ { try_files $uri =404; expires 1w; add_header Pragma public; add_header Cache-Control public; access_log off;
}
location ~* .(dat|doc|docx|dts|ppt|pptx|tar|txt|xls|xlsx)$ { try_files $uri =404; expires 3d; add_header Pragma public; add_header Cache-Control public; access_log off;
}
location = /fpmstatus { fastcgi_pass "unix:/usr/local/php-fpm-pool.d/$sockname.sock"; include /etc/nginx/fastcgi.conf; } location = /fpmping { fastcgi_pass "unix:/usr/local/php-fpm-pool.d/$sockname.sock"; include /etc/nginx/fastcgi.conf; }
location ~* /$ { index index.php; }
location ~ ^/.+ { rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
try_files $uri $uri/ /index.php;
}
gzip on; gzip_proxied any; gzip_min_length 100; gzip_buffers 8 16k; # number size, default 32 4k|16 8k gzip_types text/css text/plain text/javascript application/javascript application/json application/x-javascript application/xml application/xml+rss application/xhtml+xml application/x-font-ttf application/x-font-opentype application/vnd.ms-fontobject image/svg+xml image/x-icon application/rss+xml application/atom_xml; gzip_vary on; gzip_comp_level 9; gzip_http_version 1.0; gzip_disable "MSIE [1-6].(?!.*SV1)";
Yes I have read: o https://doc.owncloud.org/desktop/2.0/architecture.html o https://github.com/owncloud/client/issues/3946
I recently updated my Nginx server config and after reading that OC 8.1 now sends the OC-Etag header I brashly added gzip. Too soon, seems like that's going to be in Client 2.0.2, I have 2.0.1. So for a few hours of work (windows 10 PC) about a dozen files got out-of-sync with the server due to the known Etag issue.
In this case - and apparently only on windows - it's VERY hard to get it back to syncing:
Other methods, like editing the original file, saving it from Ultra-Edit to "..._2", or even moving it to a subdir or temporarily out of the syncing area, don't work. It seems that somehow the sync client (2.0.1 Windows) stores or uses a file-id in the file itself, so moving it around does'nt help.You really have to create a new file and heave the content across. What a drag...
Extended Wishlist: