error when uploading/syncing a file with special characters #34600

martink-p · 2019-02-24T16:11:25Z

Hello ownCloud developers.

I've recently installed ownCloud with the latest available docker image, set it up and configured it to use an external storage (Strato HiDrive) with encryption enabled.
While synchronizing/uploading files I ran into a problem which I could not solve. However, I could at least isolate it.

Steps to reproduce

Upload/Sync (with client) a file with special characters in name to an external encrypted stoarge. I've used "Ä cookies 5%.txt" as an example.
The operation fails with "503 Failed to check file size"
The is uploaded and the contents are encrypted. However, the file then has an urlencoded name on the storage: e.g. "%C3%84%20cookies%205%25.txt"

What I could isolate

Since that filename is obviousle urlencoded there must be some related code.
I could find it in OC\Files\Storage\DAV. That class has a function "encodePath" which is for example called from the function "rename". Within that function the filename is urlencoded and the callers probably don't notice this. I guess the remaining logic still look for the orignal name, while the file is moved and renamed on the remote storage using an urlencoded name. (The renaming is part of a call to moveFromStorage and the upload process, where the file is moved from some cache with using a ".part" upload file name to the target storage with a the "real" filename. Please don't blame me if this is not totally right, as the structure OC is really complex here.)
Simply removing the urlencoding does not work, maybe it breaks the DAV header.

Expected behaviour

The filename should match the orginal one, or at least the backend should map the name for the frontend if it really needs it encoded.

Actual behaviour

Error is reported and some backend process crashes becaus it cannot find the resource.

Server configuration

Operating system:
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Architecture: x86_64

Web server:
Latest Docker Image

Database:
Latest Docker Image

PHP version:
PHP 7.2.10-0ubuntu0.18.04.1

ownCloud version: (see ownCloud admin page)
10.0.10.4

Updated from an older ownCloud or fresh install:
Fresh Install

Where did you install ownCloud from:
Docker Image

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:

{
"system": {
"apps_paths": [
{
"path": "/var/www/owncloud/apps",
"url": "/apps",
"writable": false
},
{
"path": "/var/www/owncloud/custom",
"url": "/custom",
"writable": true
}
],
"trusted_domains": [
"localhost"
],
"datadirectory": "/mnt/data/files",
"dbtype": "mysql",
"dbhost": "db",
"dbname": "owncloud",
"dbuser": "_**REMOVED SENSITIVE VALUE**_",
"dbpassword": "_**REMOVED SENSITIVE VALUE**_",
"dbtableprefix": "oc_",
"log_type": "owncloud",
"supportedDatabases": [
"sqlite",
"mysql",
"pgsql"
],
"upgrade.disable-web": true,
"default_language": "en",
"overwrite.cli.url": "http://localhost/",
"htaccess.RewriteBase": "/",
"logfile": "/mnt/data/files/owncloud.log",
"loglevel": 2,
"memcache.local": "\OC\Memcache\APCu",
"mysql.utf8mb4": "true",
"filelocking.enabled": true,
"memcache.distributed": "\OC\Memcache\Redis",
"memcache.locking": "\OC\Memcache\Redis",
"redis": {
"host": "redis",
"port": "6379"
},
"passwordsalt": "_**REMOVED SENSITIVE VALUE**_",
"secret": "_**REMOVED SENSITIVE VALUE**_",
"version": "10.0.10.4",
"logtimezone": "UTC",
"installed": true,
"instanceid": "oc18zxbvnd2i",
"ldapIgnoreNamingRules": false,
"mail_domain": "_**REMOVED SENSITIVE VALUE**_",
"mail_from_address": "_**REMOVED SENSITIVE VALUE**_",
"mail_smtpmode": "php",
"singleuser": false,
"enable_certificate_management": true,
"forcessl": false,
"integrity.ignore.missing.app.signature": [
"encryption"
]
}
}

List of activated apps:
default plus encryption and ldap auth

Enabled:
  - comments: 0.3.0
  - configreport: 0.1.1
  - dav: 0.4.0
  - encryption: 1.3.1
  - federatedfilesharing: 0.3.1
  - federation: 0.1.0
  - files: 1.5.1
  - files_external: 0.7.1
  - files_sharing: 0.11.0
  - files_versions: 1.3.0
  - files_videoplayer: 0.9.8
  - firstrunwizard: 1.1
  - market: 0.2.5
  - notifications: 0.3.5
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - updatenotification: 0.2.1
  - user_ldap: 0.11.0
Disabled:
  - external
  - files_trashbin
  - user_external

Are you using external storage, if yes which one: local/smb/sftp/...
Yes. WebDAV, e.g. Strato HiDrive

Are you using encryption: yes/no
Yes

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
Yes. Active Directory via LDAP

Logs

Web server error log

none

ownCloud log (data/owncloud.log)

{"reqId":"yXiWbsSlWQbCEZS2tR8c","level":4,"time":"2019-02-24T10:17:39+00:00","remoteAddr":"192.168.10.51","user":"admin","app":"webdav","method":"PUT","url":"\/remote.php\/webdav\/hidrive_backup\/buero\/%C3%84%20cookies%205%25.txt",
"message":"Exception: HTTP\/1.1 503 Failed to check file size: Sabre\\HTTP\\ClientHttpException: Not Found: {
\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\ServiceUnavailable\",
\"Message\":\"Failed to check file size: Sabre\\\\HTTP\\\\ClientHttpException: Not Found\",
\"Code\":0,
\"Trace\":\"
	#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/Directory.php(172): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #86)\\n
	#1 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1095): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Directory->createFile('\\\\xC3\\\\x84 cookies 5%.t...', Resource id #86)\\n
	#2 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(525): Sabre\\\\DAV\\\\Server->createFile('hidrive_backup\\\/...', Resource id #86, NULL)\\n
	#3 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n
	#4 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n
	#5 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(479): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n
	#6 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n
	#7 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(64): Sabre\\\\DAV\\\\Server->exec()\\n
	#8 \\\/var\\\/www\\\/owncloud\\\/remote.php(165): require_once('\\\/var\\\/www\\\/ownclo...')\\n#9 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php\",\"Line\":291}"}

The text was updated successfully, but these errors were encountered:

martink-p · 2019-02-24T16:20:07Z

I might have found a solution. But, you guys should verify this because I do not have full insight in the whole process:

The destination file name of the MOVE request is also urlencoded in Files/Storage/DAV.php, where the renaming of the uploaded file is taken out in function "rename":
'Destination' => $this->createBaseUri() . $this->encodePath($path2),

Which creates such a request:

request: MOVE, https://webdav.hidrive.strato.com/users/some_path_here/%C3%84%20cookies%205%25.txt.ocTransferId231663346.part
        headers: Array
(
    [Destination] => https://webdav.hidrive.strato.com/users/some_path_here/%C3%84%20cookies%205%25.txt
)

I removed the urlencoding of "$paht2" just to see what happens. The line now is:
'Destination' => $this->createBaseUri() . $path2,

Which creates such a request:

request: MOVE, https://webdav.hidrive.strato.com/users/some_path_here/%C3%84%20cookies%205%25.txt.ocTransferId209550165.part
        headers: Array
(
    [Destination] => https://webdav.hidrive.strato.com/users/some_path_here/Ä cookies 5%.txt
)

And it works now. So obviously my conclusion was wrong because I supressed the urlencoding inside the "ecodePath" function in the first place. Thus, the uploaded part file couldn't be found anymore.

Best regards,
Martin.

ownclouders · 2019-02-24T16:36:07Z

GitMate.io thinks the contributors most likely able to help are @ownclouders, and @PVince81.

Possibly related issues are #26902 (error), #28840 (-Error-), #3088 (Special Characters error), #11681 (Errors when uploading to public folder), and #722 (file sharing error).

individual-it · 2019-02-25T06:27:33Z

@martink-p does the same thing happen on local storage?

martink-p · 2019-02-25T22:22:13Z

@individual-it I briefly reverted my change and checked it for local storage. It does not happen with local storage. But, I bet OC doesn't uses Files\Storage\DAV for local storage and there probably is no urlencoding in the chain.
However, I tested an upload during the last night and there were some new errors. They happend with files containing "#" in their name. (For example "May19#01.jpg"). With the orginal version of the function these files do work. So that character seems to break the message header again.
This is the related log:

{"reqId":"SgWM1eum0w2BPfhrEdI8","level":3,"time":"2019-02-25T21:24:18+00:00","remoteAddr":"192.168.10.51","user":"admin","app":"no app in context","method":"PUT","url":"\/remote.php\/webdav\/some_path\/May19%2301.JPG","message":"Exception: {\"Exception\":\"Sabre\\\\HTTP\\\\ClientHttpException\",\"Message\":\"Bad Request\",\"Code\":400,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Client.php(373): Sabre\\\\HTTP\\\\Client->send(Object(Sabre\\\\HTTP\\\\Request))\\n#1 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/DAV.php(531): Sabre\\\\DAV\\\\Client->request('MOVE', 'https:\\\/\\\/webdav....', NULL, Array)\\n#2 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/Wrapper.php(272): OC\\\\Files\\\\Storage\\\\DAV->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#3 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/PermissionsMask.php(86): OC\\\\Files\\\\Storage\\\\Wrapper\\\\Wrapper->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#4 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/Wrapper.php(272): OC\\\\Files\\\\Storage\\\\Wrapper\\\\PermissionsMask->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#5 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/Availability.php(295): OC\\\\Files\\\\Storage\\\\Wrapper\\\\Wrapper->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#6 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/Encryption.php(269): OC\\\\Files\\\\Storage\\\\Wrapper\\\\Availability->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#7 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/Wrapper.php(272): OC\\\\Files\\\\Storage\\\\Wrapper\\\\Encryption->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#8 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Files\\\/Storage\\\/Wrapper\\\/Wrapper.php(565): OC\\\\Files\\\\Storage\\\\Wrapper\\\\Wrapper->rename('May19#01.JPG.oc...', 'May19#01.JPG')\\n#9 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php(263): OC\\\\Files\\\\Storage\\\\Wrapper\\\\Wrapper->moveFromStorage(Object(OC\\\\Files\\\\Storage\\\\Wrapper\\\\Checksum), 'May19#01.JPG.oc...', 'May19#01.JPG')\\n#10 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/Directory.php(173): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #86)\\n#11 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1095): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Directory->createFile('May19#01.JPG', Resource id #86)\\n#12 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(525): Sabre\\\\DAV\\\\Server->createFile('some_path\\\/...', Resource id #86, NULL)\\n#13 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#14 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#15 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(479): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#16 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#17 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(64): Sabre\\\\DAV\\\\Server->exec()\\n#18 \\\/var\\\/www\\\/owncloud\\\/remote.php(165): require_once('\\\/var\\\/www\\\/ownclo...')\\n#19 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/http\\\/lib\\\/Client.php\",\"Line\":160}"}
{"reqId":"SgWM1eum0w2BPfhrEdI8","level":3,"time":"2019-02-25T21:24:18+00:00","remoteAddr":"192.168.10.51","user":"admin","app":"files_external","method":"PUT","url":"\/remote.php\/webdav\/some_path\/May19%2301.JPG","message":"Bad Request"}
{"reqId":"SgWM1eum0w2BPfhrEdI8","level":4,"time":"2019-02-25T21:24:18+00:00","remoteAddr":"192.168.10.51","user":"admin","app":"webdav","method":"PUT","url":"\/remote.php\/webdav\/some_path\/May19%2301.JPG","message":"Exception: HTTP\/1.1 503 Failed to check file size: : {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\ServiceUnavailable\",\"Message\":\"Failed to check file size: \",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/Directory.php(173): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #86)\\n#1 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1095): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Directory->createFile('May19#01.JPG', Resource id #86)\\n#2 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(525): Sabre\\\\DAV\\\\Server->createFile('some_path\\\/...', Resource id #86, NULL)\\n#3 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#5 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(479): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#6 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#7 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(64): Sabre\\\\DAV\\\\Server->exec()\\n#8 \\\/var\\\/www\\\/owncloud\\\/remote.php(165): require_once('\\\/var\\\/www\\\/ownclo...')\\n#9 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php\",\"Line\":292}"}

To me it looks like a weird implementation on the server side now, as the urlencoded version of "May19#01.jpg" is correctly renamed on the remote end but not "Ä cookies 5%.txt".
I do not see a possibility to work around this on the client side, as the file names obviously do need urlencoding and I don't see a chance to handle files with "%" in a special way. Maybe I sould inform Strato about a possible bug in their code.
However, what is weird is the crash of the server after renaming that file. Shouldn't it fail gracefully, or even not at all. Because, I think all requests do use urlencoding. Which would mean they always pass the same filename and should thus find it, even if the filename is not interpreted in the correct way. At least if the server-side bug is not limited to the MOVE request.
Maybe it needs a double check after "rename" returns before the remaining code can rely on the success of that operation. Single failing files aren't that bad, but the whole server crashing is not so good.

individual-it · 2019-02-27T13:43:30Z

to check if its a problem on stratos side you can use an other webdav client to connect directly there or use curl to send MOVE commands to strato

martink-p · 2019-02-28T00:12:46Z

Hi.
I just did this... It works pretty well. I've used the MS Windows DAV Client and tried uploading such a file and also renaming of it. I logged the communication with Message Anaylzer to see what's happening. But, there is nothing special. Uploading is done by PUT with the file part in the URI being urlencoded, and when renaming from a different file (as OC does with it's part file after upload) a MOVE message is used with file part in "Destination" header being also urlencoded.

martink-p · 2019-02-28T09:39:11Z

I'm wondering if that file name is urlencoded twice, since after the MOVE req the resulting file name is the urlencoded version of the original one...
The rename function isn't called with an url encoded file name as we can see in my previous post where I've removed the urlencoding for $path2 variable. But maybe while executing the request... ? Need to check that.

PVince81 · 2019-02-28T10:36:11Z

@individual-it can you confirm whether we have automated tests for such scenarios ? if we do then it would confirm that this is likely an env issue

individual-it · 2019-02-28T10:41:47Z

@PVince81 we do test funny char in filenames but we don't have tests with a WebDav storage and it looks to me that the code that deals with backend WebDAV storage is the problem

martink-p · 2019-03-01T21:35:19Z

Hey guys.
I have new information regarding that issue...
I did some more tests to see where the "bad guy" is hidden. I've captured the traffic from OC Docker container to the Strato server with tcpdump and on windows again with Message Analyzer.
OC uses a temporary part file (in that case "Ä cookies %.txt.ocTransferId100564105.part") and tries to rename it to the target file name "Ä cookies %.txt" with a MOVE request. The request as such succeeds:

20:39:37.246027 IP f2b561b7a14e.42040 > webdav.hidrive.strato.com.http: Flags [P.], seq 3547:3942, ack 3820, win 82, options [nop,nop,TS val 2280926955 ecr 989583231], length 395: HTTP: MOVE /some-dir/%C3%84%20cookies%20%25.txt.ocTransferId100564105.part HTTP/1.1
....:...MOVE /some-dir/%C3%84%20cookies%20%25.txt.ocTransferId100564105.part HTTP/1.1
Host: webdav.hidrive.strato.com
Authorization: Basic [auth-hidden]
User-Agent: sabre-dav/3.2.2 (http://sabre.io/)
Accept: */*
Destination: http://webdav.hidrive.strato.com/some-dir/%C3%84%20cookies%20%25.txt
Content-Length: 0
Content-Type: application/x-www-form-urlencoded

HTTP/1.1 201 Created

HTTP/1.1 201 Created
Date: Fri, 01 Mar 2019 20:39:37 GMT
Server: Apache/2.2.20 (Unix) DAV/2 mod_ssl/2.2.20 OpenSSL/0.9.8x mod_perl/2.0.4 Perl/v5.10.1
Location: http://webdav.hidrive.strato.com/some-dir/%C3%84%20cookies%20%25.txt
MS-Author-Via: DAV
Content-Length: 220
Content-Type: text/html; charset=ISO-8859-1
X-STG-FE: 10.4.1.27:10080

However, the following GET and PROPFIND requests fail with 404. The file on the remote has still an urlencoded name, but without the part-file extension (e.g. "%C3%84%20cookies%20%25.txt")

Then I did exactly the same thing with the Windows WebDAV client. I've uploaded a file with that temporary part-file name of OC and tried to rename it to the target filename manually afterwards. Guess what... It fails as well!
Being a bit curious about it because my test succeeded two days ago, I uploaded a file without funny chars and tried to rename it into "Ä cookies %.txt". It succeeded! And this is what I did two days ago, because I couldn't remember what part file names OC use... (Renaming a file with funny-chars, but with the same file extension as the target file name fails as well)

Sorry for providing misleading information. I would say this could only be a bug in Stratos WebDAV implementation, or not? If you agree I will file a bug to Strato.
However, is it really necessary to have the target name in the part file's name as well? Maybe if you try some kind of manual crash recovery... But, at least I would suggest to replace funny-chars in that part-file's name with normal representations. I think this might omit feature problems...

Best regards,
Martin.

martink-p · 2019-03-01T22:42:02Z

For example:
I changed some code in "./apps/dav/lib/Connector/Sabre/File.php"... Function "getPartFileBasePath" looks like this now:

  private function getPartFileBasePath($path) {
    $partFileInStorage = \OC::$server->getConfig()->getSystemValue('part_file_in_storage', true);
    if ($partFileInStorage) {
      $filename = \basename($path);
      $path = \dirname($path);

      $filename = iconv('UTF-8', 'ASCII//TRANSLIT', $filename); // clean up filename from funny-chars, relies on locale being set
      $filename = preg_replace('/[^A-Za-z0-9.,\-]/', '-', $filename); // Removes special chars.

      return $path."/".$filename;
    } else {
      return \md5($path); // will place it in the root of the view with a unique name
    }
  }

And it works like a charme now. The filename is cleaned up from funny-chars first and then special chars are replaced by "-". Thus, you still have a somehow related filename for the part-file.
Beforehand it was just returning $path in the if branch.

But, I've noticed something else:
If you upload a file which begins with "#" (e.g. "#oops.txt") to the WebDAV remote store, this file is displayed as a folder within OC. However, on the remote store it indeed is a file.
That has nothing to do with my code change, because I tried it without the change and the behaviour is the same. It does not happen on local storage.

individual-it · 2019-03-04T04:10:25Z

I would say this could only be a bug in Stratos WebDAV implementation, or not? If you agree I will file a bug to Strato.

By the sound of it that seems to be the core problem. To narrow it further down for Strato try to rename a file with funny char to a ASCII file name, my guess it that it also will fail

However, is it really necessary to have the target name in the part file's name as well? Maybe if you try some kind of manual crash recovery... But, at least I would suggest to replace funny-chars in that part-file's name with normal representations. I think this might omit feature problems...

CC @PVince81 @DeepDiver1975

If you upload a file which begins with "#" (e.g. "#oops.txt") to the WebDAV remote store, this file is displayed as a folder within OC. However, on the remote store it indeed is a file.
That has nothing to do with my code change, because I tried it without the change and the behaviour is the same. It does not happen on local storage.

could you please open a separate issue for that

stale · 2021-09-20T03:01:47Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

PVince81 added the bug-analysis label Mar 4, 2019

PVince81 added this to the backlog milestone Mar 4, 2019

stale bot added the status/STALE label Sep 20, 2021

AlexAndBear closed this as completed Sep 21, 2021

mrAceT mentioned this issue Dec 21, 2023

[Bug]: + (plus) character in file name causes server 500 error WITH Q&D FIX nextcloud/server#40943

Closed

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

error when uploading/syncing a file with special characters #34600

error when uploading/syncing a file with special characters #34600

martink-p commented Feb 24, 2019

martink-p commented Feb 24, 2019

ownclouders commented Feb 24, 2019

individual-it commented Feb 25, 2019

martink-p commented Feb 25, 2019

individual-it commented Feb 27, 2019

martink-p commented Feb 28, 2019 •

edited

Loading

martink-p commented Feb 28, 2019

PVince81 commented Feb 28, 2019

individual-it commented Feb 28, 2019

martink-p commented Mar 1, 2019

martink-p commented Mar 1, 2019

individual-it commented Mar 4, 2019

stale bot commented Sep 20, 2021

error when uploading/syncing a file with special characters #34600

error when uploading/syncing a file with special characters #34600

Comments

martink-p commented Feb 24, 2019

Steps to reproduce

What I could isolate

Expected behaviour

Actual behaviour

Server configuration

Logs

Web server error log

ownCloud log (data/owncloud.log)

martink-p commented Feb 24, 2019

ownclouders commented Feb 24, 2019

individual-it commented Feb 25, 2019

martink-p commented Feb 25, 2019

individual-it commented Feb 27, 2019

martink-p commented Feb 28, 2019 • edited Loading

martink-p commented Feb 28, 2019

PVince81 commented Feb 28, 2019

individual-it commented Feb 28, 2019

martink-p commented Mar 1, 2019

martink-p commented Mar 1, 2019

individual-it commented Mar 4, 2019

stale bot commented Sep 20, 2021

martink-p commented Feb 28, 2019 •

edited

Loading