Connection closed when unicode is present in filename #6516
Comments
|
The remote closing the connection seems like the server is involved, but the sync should certainly not get stuck! @JetUni Could you get another, more verbose log? (either with --logdebug or by switching on debug messages in the log window) |
|
@JetUni The sync should abort after seeing this error from the server and that can take up to 5 seconds. You are saying the folder synchronization stays in the locked-up state indefinitely and there are no more log messages? |
|
A hypothesis:
But why doesn't the 5s abort timeout fire, and why does the server close the connection in the first place? |
|
I think the sync gets stuck because the client understands the closed connection as if the connection was dropped. Edit: But this might not be the problem in this issue. |
|
@ckamm @ogoffart shouldn't the filename on the logs from the propagator be already normalized? the multiple " @JetUni are you using some particular storage option as destination of your local sync folder? |
|
Also, after #5661 sync should not be affected at all if one of these pops out in the process. |
|
@JetUni since:
If you are also unable to create files with 4-byte characters on its name via webUI, check owncloud-docker/base#4 (comment) for some instructions on how to migrate your DB to support these. |
|
Right, the fact that it is not proper in the log is indeed quite strange. |
Previously it tried to abort even jobs that had already finished, which was not going to work as they wouldn't emit finished() again. Also, in some cases the abortCount would never go to zero and that case wasn't well documented.
|
I've cleaned up the upload abort code, but my guess was wrong: If a job has a fatalError in done() it'll not be in |
Running |
I tried to limit the log as much as I could to give you just what you needed, but here is a log from the debug window taken today. https://gist.github.com/JetUni/4deaf40e1b1c8ca49b2c06b02d03a730
See the log in the gist above, but basically there are 166 files trying to be synced in that gist and once it gets to the file with the unicode character, it stops. In this case, the problem file is number 34 or something like that, and so it only syncs 33 files.
I'm not sure I know what you mean. Does the log answer your question? If not, could you be more specific? |
|
@JetUni glad to hear the DB commands worked out. Agree it should not block the syncing process; we will check for further client issues and track the progress here. With "particular storage option as destination of your local sync folder" I meant if you e.g. might be using a different file system on the drive you're placing your sync that might have troubles with the filename encoding. |
|
Both of my drives are formatted as ext4. The first device is the main OS drive and the second is my "Data" drive. I hope this helps you understand what's going on.
$ cat /var/www/owncloud/config/config.php | grep datadirectory
'datadirectory' => '/media/Data/ocdata',
|
Related: #5859 (Never ever abort sync runs) /cc @SamuAlfageme |
|
@JetUni Thanks for the full log! So the propagator doesn't get stuck, but the sync aborts when a "Connection closed" error is encountered. Currently all network errors (Proxy, ssl. timeouts etc) are considered fatal. We could make @ogoffart Your thoughts? |
Previously it tried to abort even jobs that had already finished, which was not going to work as they wouldn't emit finished() again. Also, in some cases the abortCount would never go to zero and that case wasn't well documented.
See my first comment to this issue. Where I suggested to do a connectivity check before aborting the sync. But maybe you are right, RemoteHostClosedError probably does not indicate a connectivity error and we probably could classify it as a "NormalError" |
Because it sometimes appears in conjunction with server bugs and we don't want to halt all syncing for other files in these cases.
Because it sometimes appears in conjunction with server bugs and we don't want to halt all syncing for other files in these cases.
|
@SamuAlfageme The specific thing that is done and could be tested is that ConnectionClosed will no longer abort the sync. |
|
I'm using a proxy to drop the Error is displayed prominently (i.e. up 'till the very tray menu) until the file gets to download, sync is never aborted/dropped. I'd say this can be closed 👍 |
Expected behaviour
The file should sync with the server, even if there is a Unicode character (specifically an emoji) in the filename
Actual behaviour
There is an error "Connection closed" and the syncing stops entirely. It won't even move on to the next files. At the very least it should move on and try that file again before it finishes syncing, but instead it just stops everything.
Steps to reproduce
Server configuration
Operating system:
Ubuntu 16.04
Web server:
Apache
Database:
MySQL
PHP version:
7.0.28
ownCloud version:
10.0.8.5
Storage backend (external storage):
Stored locally, Cached with Redis
Client configuration
Client version:
2.4.1
Operating system:
Windows 10
OS language:
English
Installation path of client:
A:\C\Program Files (x86)\ownCloud
Logs
Web server error log:
None
Server logfile: ownCloud log (data/owncloud.log):
None
The text was updated successfully, but these errors were encountered: