Client: Wrong private links copied to clipboard from file manager integration

[PVince81]

Steps

1. Save a PDF file in a folder somewhere in the ownCloud folder
2. Open file manager (in my case Dolphin on openSUSE Tumbleweed)
3. Right click on PDF file
4. Select "Copy private link to clipboard"
5. Paste it somewhere
6. Now go to web UI and copy the private link from the web UI
7. Compare the link

Expected result

Links are exactly the same

Actual result

Link from web UI is correct and ends with "/f/210065".
Link from desktop client end with "f/00210065507"

Another link:
Web UI: "/f/175070"
Desktop client: "/f/00175070507"

It seems that some part of the string is repeated.

Version

2.4.3

I have verified that oc:privatelink for said files is correct and it matches what the web UI shows, so the bug is likely in the client.

I also seem to remember that this worked before so it could be a regression.

@guruz @ogoffart

[ogoffart]

@PVince81 And what is the file id? is it by any chance what is in the "wrong" url? I guess the "507" may be a part of the server instance.
Normaly, we'd use oc:privatelink, but we fallback to the fileid, for which we take the numeric part of the file id.

We fallback to the fileid if for some reason the PROPFIND is failling.

[PVince81]

Hmm, it works fine with the same client on cloud.owncloud.com.

Both instances are on 10.0.9.

You're right, the 507 is the 3 first digits of the instance id.

Here are the values of the fileid properties for the second test file:

        <oc:id>00175070507a979be894f</oc:id>
        <oc:fileid>175070</oc:fileid>

[PVince81]

and this is for a file on cloud.owncloud.com:

        <oc:id>00794381oce9akr7u3v9</oc:id>
        <oc:fileid>794381</oc:fileid>

Seems like my instance id is missing a "oc" in front ? This hasn't changed over the last years.

I'll also check the file ids in the sync DB then

[PVince81]

fileid of the test file on my instance is "00175070507a979be894f"

Note: the fileids above were all retrieved using PROPFIND, so I don't think there was a failed PROPFIND involved. It took about 2 seconds on my own server but I don't think the client would give up after such short time ?

[ckamm]

@PVince81 Yes, the deprecated-fallback id is constructed by matching ^[0-9]* against the full id. That's where your bad ids come from - the assumption back then was that the instanceid would always start with "oc". This should only ever happen if the propfind to retrieve the real fileid and the privatelink url fails.

[PVince81]

hmm, my instance is very old, probably started with OC 4.5 or so.
it is likely that there are other instances without "oc" in front.

I think we added the "oc" later on because some people were unlucky and had randomly generated instance ids with only digits, where "0123456" would be converted to an int in PHP. The workaround was to prepend an "oc" to make sure PHP's automagic would leave it as a string.

Next up: find out when "oc" was introduced.

[PVince81]

and: find out why the fallback is being used at all in my scenario

[ogoffart]

Works for me: The private link url is correctly fetched from the private link property in the propfind.

Can you check in the client log if there is an error while doing the PROPFIND?

[PVince81]

PR that introduces "oc" prefix in instanceid: https://github.com/owncloud/core/pull/2584 and commit is tagged with OC v6.0.0RC1. So all instances that were setup before that would be at risk in case the fallback is used.

Now I'm not sure if we can ask people to manually change the instanceid as many things are linked to it. In the past, the passwords were hashed based on it. Need to carefully check if we want to advise to change it.

I'll now check the client log to find out why the fallback is used.

[PVince81]

@ogoffart nothing appears in ".owncloudsync.log" when I right click the test file and select "Copy private link to clipboard"

[PVince81]

this is with "owncloud-client-dolphin"

[PVince81]

Ok, got a 404. Let me sanitize the log

[PVince81]

Aha, I think I'm onto something: the file is actually located on my OC in "/clientsync/julius.txt" as I chose to synchronize only that folder. So the remote folder "/clientsync" maps to "$HOME/Private/ownCloud" locally.

The URL that is queried is "https://owncloud.vincentpetry.net/remote.php/dav/files/vincent/julius.txt" which is missing "clientsync" prefix. See below:

08-28 11:32:59:071 [ info gui.socketapi ]:      Received SocketAPI message <-- "COPY_PRIVATE_LINK:/home/vincent/Private/ownCloud/julius.txt" from QLocalSocket(0x7f9300006590)
08-28 11:32:59:071 [ debug sync.database.sql ]  [ OCC::SqlQuery::bindValue ]:   SQL bind 1 QVariant(qlonglong, 7973444805910989799)
08-28 11:32:59:071 [ debug sync.database.sql ]  [ OCC::SqlQuery::exec ]:        SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
08-28 11:32:59:072 [ info sync.accessmanager ]: 6 "PROPFIND" "https://owncloud.vincentpetry.net/remote.php/dav/files/vincent/julius.txt" has X-Request-ID "313968d4-3361-4157-a476-c1506d4285e4"
08-28 11:32:59:072 [ debug sync.cookiejar ]     [ OCC::CookieJar::cookiesForUrl ]:      QUrl("https://owncloud.vincentpetry.net/remote.php/dav/files/vincent/julius.txt") requests: (QNetworkCookie("oc_sessionPassphrase=REMOVED; secure; HttpOnly; domain=owncloud.vincentpetry.net; path=/"), QNetworkCookie("REMOVED; HttpOnly; domain=owncloud.vincentpetry.net; path=/"))
08-28 11:32:59:072 [ info sync.networkjob ]:    OCC::PropfindJob created for "https://owncloud.vincentpetry.net" + "julius.txt" "OCC::SocketApi"
08-28 11:32:59:788 [ warning sync.networkjob ]: QNetworkReply::NetworkError(ContentNotFoundError) "Server replied \"404 Not Found\" to \"PROPFIND https://owncloud.vincentpetry.net/remote.php/dav/files/vincent/julius.txt\"" QVariant(int, 404)
08-28 11:32:59:788 [ info sync.networkjob.propfind ]:   PROPFIND of QUrl("https://owncloud.vincentpetry.net/remote.php/dav/files/vincent/julius.txt") FINISHED WITH STATUS QNetworkReply::NetworkError(ContentNotFoundError) "Server replied \"404 Not Found\" to \"PROPFIND ht

[PVince81]

I've raised https://github.com/owncloud/client/issues/6745 for the "oc" in instance id to discuss alternatives.

Let's keep this ticket here for the 404 issue only.

[ogoffart]

I believe the 404 issue was fixed by commit 93d8810414d94cdb2b7e7adf00d2f58e5e3098a0 (in 2.5)

Hence i'm adding the ReadyToTest tag

[guruz]

@PVince81 Could you test if 2.5.0 fixes this?

[PVince81]

Tested with 2.5.0, private links are now correct in my local sync setup with custom folder as described in https://github.com/owncloud/client/issues/6742#issuecomment-416517250