Windows 10 Client very difficult after sync of particular files has failed

[timreeves]

Yes I have read:
o https://doc.owncloud.org/desktop/2.0/architecture.html
o #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:

• Create a new text document with default name in the same directory
• Heave the content across in an editor
• Delete the old file, then rename the new document to the name of the deleted file

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:

• Eliminate the blinking of OC-Icons in Windows Explorer when Sync-Client ist active (loss of focus during drag + drop or renaming causes havoc)
• Options in OC-Client
  (1) to choose the GUI language, and
  (2) to optionally NOT display the ignored files in the activity log GUI (can't see the wood for the trees)
  (3) let people know when all clients have been updated to recognise OC-Etag

[ogoffart]

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.

[timreeves]

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

[timreeves]

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

[timreeves]

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:

• I now turned gzip on in Nginx - seems to work
• But those funny errors in the client log WHEN the server returns a 404 still look disconcerting ("Failed to resolve EGL function eglGetPlatformDisplayEXT").
• Wishlist 1: Eliminate the blinking of OC-Icons in Windows Explorer when Sync-Client ist active (loss of focus during drag + drop or renaming causes havoc)
• Wishlist 2: Option in OC-Client to choose the GUI language
• Wishlist 3: Option in OC-Client to optionally NOT display the ignored files in the activity log GUI

My Nginx-Config for PHP-FPM (running on a Plesk VPS, but outside of Plesk, an own compiled PHP):

---

Folgende Anweisung werden am Ende von jedem Server-Block, also in "server { ... }" context, includiert.

include "/var/www/vhosts/{plesk-webspace}/{domain-docs-dir}/nginx-for-own-phpfpm-owncloud.conf";

set $sockname ##YOUR-WS##;

Plesk Web Server settings:

NO PHP support

Smart static files processing = Nein

Serve static files directly by nginx = Nein

After each modification: service nginx restart

Nginx Server Error log: /var/log/nginx/error.log

Nginx Domain Error log: /var/www/vhosts/system/{domain}/logs/error_log

FPM-Log (Server + alle Domains): /var/log/php5-fpm.log

http://wiki.nginx.org/Pitfalls

http://www.php.net/manual/de/regexp.introduction.php

https://doc.owncloud.org/server/8.1/admin_manual/installation/nginx_configuration.html

Plesk's "location /" sends the resource request to Apache via Ports 7080/7081

Plesk's "location /" is the ONLY prefix string location in the Plesk config,

which means it's always the winning prefix location, and gets noted as such.

- UNLESS we add any longer prefix string locations...

Implying that if we want to use Nginx for everything, then we must add

"location" statements matching ALL resource types we expect, with "try_files".

Security via e.g. "try_files" is NOT an issue at "location /", that's then Apache's job.

if ($server_port = 80) { rewrite ^ https://$server_name$request_uri? permanent; }

Adds the specified charset to the “Content-Type” response header field.

Context: http, server, location, if in location

charset utf-8;

Disable gzip to avoid the removal of the ETag header

Seems fixed in OC8.1 - owncloud/core#15227, owncloud/core#9005

Background: https://github.com/owncloud/client/wiki/Etags-and-file-ids

Client + Server: #3946

gzip off;

Add headers to serve security related headers

add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";

add_header X-Content-Type-Options nosniff;

add_header X-Frame-Options "SAMEORIGIN";

add_header X-XSS-Protection "1; mode=block";

add_header X-Robots-Tag none;

error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;

client_max_body_size 10G;

fastcgi_buffers 64 4K;

error_log /var/log/nginx/error.log debug;

location = /robots.txt { allow all; log_not_found off; access_log off; }
location = /nginx-for-own-phpfpm-owncloud.conf { deny all; return 404; }

Then comes regex processing, *** which terminates on the first match ***, and the

corresponding location configuration is used. If no match with a regular expression

is found, then the configuration of the prefix location remembered earlier is used.

SO the order in which regex locations appear is IMPORTANT!

(?: ... ) non-capturing, siehe https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck

Hide sensitive areas not needing direct user access

First regex match attempt ensures deny all really happens on match

location ~ ^/(?:.|3rdparty|config|console|db_structure|indie|lib|occ|templates).* { deny all; return 404; }

ownCloud 8 nutzt PATH-INFO to .js and .php, e.g. /index.php/core/js/oc.js,

/index.php/core/ajax/share.php, /index.php/apps/files/ajax/list.php, /index.php/avatar/TimReeves/128

PHP-Handling: Best of Plesk and ownCloud and Web-Forum articles

A match here pre-empts Plesk's "location /", sends the script to PHP-FPM

"(?U)" sets internal "ungreedy" option, i.e. to FIRST ".php" - NEED THIS HERE for PATH-INFO requests

location ~ ^((?U).+?.php)(/.*)?$ {

TR: See http://wiki.nginx.org/HttpFastcgiModule#fastcgi_split_path_info

TR: Directive populates $fastcgi_script_name + $fastcgi_path_info

TR: BUT there's a problem: http://trac.nginx.org/nginx/ticket/321

fastcgi_split_path_info ^((?U).+.php)(/?.+)$;
set $path_info $fastcgi_path_info;

Requested PHP Scripts MUST exist exactly as named

try_files $fastcgi_script_name =404;

try_files has emptied $fastcgi_path_info

fastcgi_param PATH_INFO $path_info;

You can add any application-special headers to $_SERVER here

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";

TR: Sets SCRIPT_FILENAME as $document_root$fastcgi_script_name

TR: Meaning that $fastcgi_script_name MUST be correct now!

include /etc/nginx/fastcgi.conf;

access_log off;

}

Plesk's Directives for Web User Access are not needed on this domain!

The "generic" handling of static resources

Note that they are all formulated securely with "try_files".

PUT MOST FREQUENT FIRST

try_files "uses the first found file for request processing; the processing is performed in the current context"

Frequent possibly modified content valid 1 day in Cache

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;

add_header Debug Frequent;

}

Pics and Fonts valid 30 Days in Cache

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;

add_header Debug PicFont;

}

Zips + PDF valid 2 weeks in Cache

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;

add_header Debug ZipPDF;

}

Media files (large) valid 1 week in Cache

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;

add_header Debug Media;

}

Infrequent possibly modified content valid 3 days in Cache

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;

add_header Debug Infrequent;

}

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; }

Virtually nothing should arrive here: We've already (hopefully) done any

special protected / allowed locations, all ".php" scripts, all static assets.

location ~* /$ { index index.php; }

location ~ ^/.+ {
rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

Allow the unrecognised type to be a file or directory, redirect all else to /index.php

try_files $uri $uri/ /index.php;

Let this be logged – we want to know of anything untoward!

}

Finally, switch gzipping on

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)";