Endless Loop on syncing folders with special char (Umlaut) about client HOT 6 CLOSED

As you can see in the Server log the url is encoded, and Bügel1 is encoded to Bu%cc%88gel1 which appears to be correct as you can test on various online tools. Your server however does not seem to be able to deal with that encoding properly. Would you be so kind to check the apache error log if you can see if it shows errors on that?

For me, Bügel1 works fine, but my client encodes Bügel1 to B%c3%bcgel1 which also is correct. The encoding is done by ne_path_escape of the neon lib. It boils down to this code:

   for (pnt = (const unsigned char *)path; *pnt != '\0'; pnt++) {
        if (path_escape_ch(*pnt)) {
            /* Escape it - %<hex><hex> */
            sprintf(p, "%%%02x", (unsigned char) *pnt);
            p += 3;
        } else {
            *p++ = *pnt;
        }
    }

and I wonder how this can produce the different output on the platforms.

from client.

except from the message Password Mismatch its empty, but I think that is normal,
Seems to happen on every access, even on folders that are ok.

==> error.log <==
[Mon Nov 05 22:00:53 2012] [error] [client x.x.x.x] user username: authentication failure for "/webdav/owncloudTEST/Bu\xcc\x88gel1": Password Mismatch
[Mon Nov 05 22:00:53 2012] [error] [client x.x.x.x] user username: authentication failure for "/webdav/owncloudTEST/Bu\xcc\x88gel1": Password Mismatch
[Mon Nov 05 22:00:53 2012] [error] [client x.x.x.x] user username: authentication failure for "/webdav/owncloudTEST/Bu\xcc\x88gel1/": Password Mismatch

I connected with a webdav client (cyberduck) and created the same Folder.
That one works fine and uses your %c3%bc encoding.

==> access.log <==
x.x.x.x - username [05/Nov/2012:22:24:27 +0100] "MKCOL /ocloud/remote.php/webdav/owncloudTEST/B%C3%BCgel2/ HTTP/1.1" 201 1580 "-" "Cyberduck/4.2.1 (Mac OS X/10.7.5) (i386)"
x.x.x.x - username [05/Nov/2012:22:24:36 +0100] "PROPFIND /ocloud/remote.php/webdav/owncloudTEST/B%C3%BCgel2/ HTTP/1.1" 207 1255 "-" "Cyberduck/4.2.1 (Mac OS X/10.7.5) (i386)"

path_escape_ch - I hate such complex defines, cant say i really understand it.

As far as i understand it, OSX hamdles special chars with the
NFD-Form (Unicode normalization form D)
NFD: "u%CC%88"

other OS's or applications seem to prefer
NFC-Form (Unicode normalization form C)
NFC: "%C3%BC"

maybe the webdav server could run a function like this before it handles the url
if (!normalizer_is_normalized($uri)) {
$uri = normalizer_normalize($uri);
}

from client.

I'm experiencing that a customer is causing a loop with it's client sync. This same log entry loops over and over twice every second. It gives an error 404, which might be a bug with special characters? Our primary customers are Danish which means that they are using characters like: æ, ø and å.

[20/Nov/2012:10:52:12 +0100] "PROPFIND /remote.php/webdav/F%c3%b8rstehj%c3%a6lp.com/1-Kunder/2012/Salg%20af%20hjertestartere/8-Give%20st%c3%a5lsp%c3%a6r%20-%201%20zoll%20%2b%206%20timer%20FH/2012-3-Give%20st%c3%a5lsp%c3%a6r%20-%206%20timer%20FH%20og%20ZOLL/SV%20tilbud%20fra%20F%c3%b8rstehj%c3%a6lp.com-filer HTTP/1.1" 404 874 "-" "csyncoC/0.60.1 neon/0.29.6"

The folder mentioned is existing, but no files are located in that folder at the moment.

A little more information from apache error.log to assist you.

[Tue Nov 20 10:36:17 2012] [apc-warning] Potential cache slam averted for key '50a25a3fcdc6e/[email protected]/fileid//[email protected]/files/Førstehjælp.com/1-Kunder/2012/Salg af hjertestartere/8-Give stålspær - 1 zoll + 6 timer FH' in /var/www/cloud/lib/cache/apc.php on line 35.

[Tue Nov 20 10:53:47 2012] [error] [client 87.59.192.118] PHP Notice: session_start(): ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13) in /var/www/cloud/lib/base.php on line 265

The OS is ubuntu 10.04.

from client.

I implemented a loop detection in csync today so that the mkdir routine can not loop any more. That will fix the symptom, but it will not fix the underlying issue of rong encodings.

from client.

A similar bug, from Bug Genie for Korean language:
http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-1341

Description:

1. Client sync does not working at Korean named files
2. Korean named files download error.

icon_edit.png Reproduction steps:

1. Sync the Korean named files. And delete it. It does not works for server with another client.

• http://www.youtube.com/watch?v=OV9RYf9V5B0

1. Share the Korean named files. And download it. File name disappeard.

• http://www.youtube.com/watch?v=IQAAeokNQRY

from client.

Problem solved with OSX Client 1.1.4

Mirall/ownCloud Client, version 1.1.4
csync 0.60.4 required.

• No changes to mirall/ownCloud Client source.
• [Fixes] csync: Fix encoding issues on MacOSX clients, now the client sends normalized unicode on that platform.

Thanks!

from client.