Don't rely on instance id oc prefix when parsing file id

[PVince81]

See #6742 (comment)

In general the client could use the newer "oc:fileid" property and store it separately from the instance id.

If the instance id is needed, we could expose it as well in the capabilities if not already.

[ogoffart]

The client does only try to extract the fileid as a fallback, if the PROPFIND fails. or if the server do not support oc:fileid.

Since what version of the server can we assume there exist oc:fileid?

#5763 (comment) Discuss that we could use oc:fileid instead of oc:id in the database itself.

[PVince81]

The "oc" prefix exists since OC 6.

Any install that was setup before that, like mine, still have the old instance id as we don't regenerate it automatically as it could cause side effects.

[ogoffart]

But since when do the properties http://owncloud.org/ns:fileid and http://owncloud.org/ns:privatelink exist? Can we assume they are there on every supported server?

[ckamm]

The fileid is only extracted from the full id in this way if fileid and privatelink aren't available. (due to network errors or old servers). What we could do is use the first 8 bytes, instead of ^[0-9]*. However, there is an explicit test for "When the numeric id overflows the 8-digit boundary" - so possibly that wouldn't be right everywhere either.

Use the first 8 byte if the first character is a 0, otherwise scan for the first letter?

[PVince81]

using the first bytes could become unreliable once the fileid becomes longer, see owncloud/core#26901

[PVince81]

• http://owncloud.org/ns:fileid exists since OC 9.0beta1: owncloud/core@978303e
• http://owncloud.org/ns:privatelink exists since v10.0.4

[ckamm]

This is only for the legacy codepath so I think it's low importance. Nevertheless I will improve the heuristic for extracting the fileid from the id for the legacy case in 2.5.0.

In the future we should indeed think about migrating to just using the fileid instead of the id. This will likely need to be done over a long time period to ensure database interoperability: first start storing the numeric id as well in a separate field, then later drop the id. Currently there's no urgent need for it.

[PVince81]

Agreed about low prio. If the 404 is solved in 2.5.0 (I need to test it), then the problem will likely disappear. (ref: #6742)

[TheOneRing]

Legacy private links where removed in 2.7