Orphaned blobs when creating versions

[kobergj]

Ocis creates orphaned blobs when the same file is uploaded multiple times.

• Upload a file
• Upload the same file again (using "replace" in the webui)
• Upload the same file a third time
• check consistency with ocis backup consistency
  -> There is an orphaned blob in the blobstore
  -> The file has only version

That the file has only one version might be expected behaviour because it is the same file after all. But there should not be an orphaned blob because of this.

Note that this doesn't happen if you upload a file with different content but the same name. Versions are created as expected and there is no orphaned blobs.

[kobergj]

Found the reason:

decomposedfs is creating a pattern nodeid.REV.mtime for the revisioned node. If uploading the same file multiple times, web will send the mtime it reads from the disk. Since the mtime will always be the same (if the file is not modified) ocis will just overwrite the revisioned node with new blob metadata. This is why ocis just forgets the blob in the blobstore and moves on.

[nirajacharya2]

this issue is not completely fixed.

i wrote test coverage for this issue but the build is failing. build: https://drone.owncloud.com/owncloud/ocis/40465/45/7

there might be no orphan blobs created when using web but for api there is still a problem.

curl 'https://localhost:9200/remote.php/dav/spaces/38dc8973-f414-4187-af95-61af28dcaecc$1766a972-63c1-44ec-bc87-47f8738aaf5e' \
  -H 'Content-Type: application/offset+octet-stream' \
  -H 'Tus-Resumable: 1.0.0' \
  -H 'Upload-Length: 28' \
  -H 'Upload-Metadata: mtime MTczMDE2MDAwMA==,filename L3RleHRmaWxlLnR4dA==' \
  -d'This is a testfile.

Cheers.' \
  -uadmin:admin -vk

🚨 Inconsistent Blobs:
        👉️ [blob orphaned]      blob: /home/niraj/.ocis/storage/users/spaces/ac/9e64ed-de6e-42f6-9d9d-b85f7376a1f0/blobs/5f/32/e4/59/-4498-4dd3-afa2-4bf60b20a28f

CC @kobergj

[saw-jan]

FYI, this is not the case with webUI upload (TUS upload). Same actions via webUI doesn't create an orphaned blob

[kobergj]

Escalated to p2 as orphaned blobs are bad

[kobergj]

I had a short look on it. Something seems very broken. When executing above curl for the 3rd time an orphaned blob will be created. Running it again will not increase the amount of orphaned blobs. It will always only be one. When restoring a version via web ui the version gets lost and the blob stays orphaned.

This is only happening when upload the exact same bytes, so it will not lead to data loss, still we should investigate this within this release.

[rhafer]

Uff. The revision files created by the above curl command don't have the sub-second component:

./spaces/03/a7a081-13b4-488d-bdd6-a35c3297f11b/nodes/00/3c/9d/29/-ddb6-4776-817a-c1356d9b5df3.REV.2024-10-29T00:00:00Z

vs. a "normal" revsion:

spaces/03/a7a081-13b4-488d-bdd6-a35c3297f11b/nodes/39/8e/d5/5d/-8440-4cb5-a6bd-cef503312e33.REV.2024-11-06T12:36:31.329276837Z

The ocis backup command does not treat the first one as a valid revison file and basically ignores it. So this is acutually a bug in ocis backup. (But I guess we should also fix the versioning code to always include the nano seconds, even if zero)

[rhafer]

The above PR fixes the issue with the backup consistency checker. The "orphaned blob" error simply was a false positive.
However there still seem to be some issues with revsions.

When uploading a file with the same mtime and name but different contents multiple times, I get "500 Internal Server Error" for all uploads after the 2nd upload. (I'll create a separate issue for this)