Moving files from "file storage" to "S3" fails with undefined local variable `content_type`

[saz]

Used Zammad Version

6.3

Environment

• Installation method: docker
• Operating system (if you're unsure: cat /etc/os-release ): ubuntu 20.04
• Database + version: postgresql 14
• Elasticsearch version: 7.17
• Browser + version: Google Chrome 129

Actual behaviour

Trying to migrate files from file storage to S3 via CLI. The following error is shown:

NameError: undefined local variable or method `content_type' for Store::Provider::S3:Module
from /opt/zammad/app/models/store/provider/s3.rb:13:in `add'

It seems like, as if it's unable to read the file. Running a Store::File.verify() shows the following error:

Errno::ENOENT: No such file or directory @ rb_sysopen - /opt/zammad/storage/fs/7546/7b35/56b2f/ae8b8/5f59cc5/a9db84b/49948d505cacdbedd594707d5d40c447
from /opt/zammad/app/models/store/provider/file.rb:30:in `binread'

Creating an empty file and running Store::File.verify(fix_it=true) shows the following error:

RuntimeError: File corrupted: path /opt/zammad/storage/fs/7546/7b35/56b2f/ae8b8/5f59cc5/a9db84b/49948d505cacdbedd594707d5d40c447 does not match SHA digest (fa2932c81d7
f65b1ab9e1eb9d64e9ec7ccf03e4a1cfc0a93ed273a748093460e)
from /opt/zammad/app/models/store/provider/file.rb:34:in `get'

Expected behaviour

Moving files from one storage type to the other works or shows a proper error message, if something's wrong with the source file.

I think the error shown during a Store::File.verify(fix_it=true) run is another bug, as it never reaches the code to update the sha

Steps to reproduce the behaviour

• Set up file storage
• add some tickets with attachments
• delete a random file within the file storage
• try to move to the S3 storage

Support Ticket

No response

I'm sure this is a bug and no feature request or a general question.

yes

[tschaefer]

This is independent of the store source/target system. If a file (or the relation) is missing the Store::File.move method crashes with a respective error.

[martini]

I see two topics here:

a) Zammad issue in app/models/store/provider/s3.rb (we need to fix this)

 NameError: undefined local variable or method `content_type' for Store::Provider::S3:Module
from /opt/zammad/app/models/store/provider/s3.rb:13:in `add'

b) Local issue, seems that files are lost and content of files has changed (the error is not due to Zammad, it is an operational error - perhaps the hard disk was full or similar.)

Errno::ENOENT: No such file or directory @ rb_sysopen - /opt/zammad/storage/fs/7546/7b35/56b2f/ae8b8/5f59cc5/a9db84b/49948d505cacdbedd594707d5d40c447
from /opt/zammad/app/models/store/provider/file.rb:30:in `binread'

RuntimeError: File corrupted: path /opt/zammad/storage/fs/7546/7b35/56b2f/ae8b8/5f59cc5/a9db84b/49948d505cacdbedd594707d5d40c447 does not match SHA digest (fa2932c81d7
f65b1ab9e1eb9d64e9ec7ccf03e4a1cfc0a93ed273a748093460e)
from /opt/zammad/app/models/store/provider/file.rb:34:in `get'

For the second one we offer assistance via support, see https://zammad.com/en/pricing#selfhosted

[saz]

@martini I understand the part about missing files and fixing it is out of scope within the issue, but I still believe that running verify(fix_it=true) is broken.

It's trying to get the file, but within the get() method, the stored sha gets compared against the file content of the file stored within the file system. This is failing, as it's obviously not matching. verify(fix_it=true) is supposed to update the sha attribute, but never reaches the point.

For me, only three files are broken and I can easily create them, but my expectation would have been, that a verify(fix_it=true) would update the sha, if it's not matching and there's a file within the stored location