Core: issue with german umlauts in linux with desktop client

Created on 12 Jun 2014 · 20Comments · Source: owncloud/core

http://storage9.static.itmages.com/i/14/0612/h_1402580388_7910081_44c8911181.png

Hi,
when sharing files containing german umlauts in file name, the files will be synced locally by linux 1.6.0. client properly, modifying these files ends up in creating asci symbols in files or break sync.

Underlaying OS: Debian Wheezy 7.5 64bit

This effect does not occur for actual Windows or Mac client.
Folder names may contain umlauts with no issue occuring under linux client.

is this issue already known?

Bug sev3-medium

Source

sknohsalla

Most helpful comment

should be fixed. utf-8 is a hard requirement now

karlitschek on 24 Mar 2015

👍2

All 20 comments

So your server runs on Debian Wheezy ? And the locale is setup correctly there ?
Are you using the external storage app ?

PVince81 on 12 Jun 2014

Yes, server and client are running under Wheezy
server: 7.4 amd64
client: 7.5 amd64
storage app: no

server locale:
locale
LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE=C
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

client locale:
locale
LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE=C
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

Do u need further information?

Thanks in advance!

Cheers, Sven.

sknohsalla on 13 Jun 2014

Hmm, can you try switching the server locale to en_US.UTF8 ?
I suspect that the default en_US locale is using a different encoding.

PVince81 on 13 Jun 2014

@sknohsalla Is this resolved with the settings?

MTRichards on 20 Jun 2014

Moving to oC 7.0.1

craigpg on 26 Jun 2014

@sknohsalla any update ? Did it work with the locale change ?

PVince81 on 15 Jul 2014

Are your clients running with a utf8 locale?

danimo on 5 Sep 2014

HI @danimo and @PVince81 and sorry for the late reply !

Both, server and client site are running with en_US.UTF8.
We"re currently testing on a demo instance.
Will give an update as soon as possible.

Thanks for the understanding!

Cheers, Sven.

sknohsalla on 22 Sep 2014

@sknohsalla Any update?

LukasReschke on 30 Oct 2014

@sknohsalla Can you try with the latest 7.0.4 and 1.7 please?

karlitschek on 5 Dec 2014

@karlitschek, did try with :

Debian 7.7 latest 64bit
OwnCloud 7.04 & linux client 1.70

still same issue even UTF-8 is set explicitly:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Working only if adding file with umlauts directly via https(browser).
Linux client is downloading this file then as expected.

Upload ends up in log:
��.txt - No such file or directory

If u need further information, please let me know.

sknohsalla on 6 Jan 2015

@danimo @dragotin shall we move this issue over to the client tracker? Not really much we can do here on the server side - THX

DeepDiver1975 on 8 Jan 2015

Well, sounds like the server is still running on en_US and not UTF8 according to the log above, see _server locale_. @sknohsalla could you double check that both client and server run in a proper UTF8 environment? Thanks.

dragotin on 8 Jan 2015

Also, when you changed the locale on either server or client, the journal database might be screwed as it was written with the non utf8 locale eventually.

dragotin on 8 Jan 2015

@dragotin en_US is the collation. Afaik, if the utf-8 is missing, and nothing else is specified, utf-8 should be implied on all Linux distros that are not 10 years old. Still this should be double-checked.

danimo on 8 Jan 2015

on server
Debian 7.7 64bit

dpkg-reconfigure locales
Generating locales (this might take a while)...
en_US.UTF-8... done
Generation complete.

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

on client
Debian 7.7 64bit

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

@danimo , yes UTF-8 wasn't missing, but not set as default.
@dragotin is there a way to clean the journal database ?

below, Browser, Nautilus and activity log from owncloud client:
selection_032

sknohsalla on 8 Jan 2015

So umlauts will just be cropped, eg vü3rdtestfile will turn into v3rdtestfile on linux client.

sknohsalla on 8 Jan 2015

For the client, you can simply delete the files .csync_journal.db* while the client is stopped. It will recreate the journal. But I am not sure if that helps. You should not do that to the server db content btw.

dragotin on 8 Jan 2015

Happens for me too, under weird circumstances. Creating a directory 'täst': works and is synched to server. Also appears on web frontend. Creating a file 'täst.txt' inside 'täst': Does not sync, client shows 'File not found'. Checking the folder in web frontend again, it is named 'tst'. So in fact, the sync process does maim the folder name after it was once synced successfully.
This looks arkward, as changing the folders contents seem to trigger the erratic rename.